Advice needed, VS.NET versions, MC++ compiler bug, boxing and more

  • Thread starter Thread starter STG
  • Start date Start date
S

STG

Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached critical mass
and I am now in the process of doing that.

Actually, the first release of this 'port' is be a simple rebuild of the
unmanaged C++ SDK in VS.NET. I have done this part already, using VS.NET
2003. [This will allow VS.NET users to debug with our SDK without having to
manually pull in the VC++ 6.0 debug DLLs.]

The reason I chose to use VS.NET 2003 was that this is a seachange for me,
and all of the books and references I have acquired reference Managed C++.
I thought I could stand to learn the concepts with the references I had and
then switch to VS 2005/C++/CLI, knowing that this will represent another (if
smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for the
unmanaged SDK. I had planned for this to be done in VS 2005 using C++/CLI,
after a bit of a learning curve. It's a pedestrian approach, I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application for my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++ 7.1
compiler:

My SDK unmanaged class has the following declarations:

typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;

class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...

};

In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;

__box( device.FindCnx() ); // This line produces a compiler
error: error C3149: 'System::Enum' : illegal

// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at runtime,
won't it?
}
}

From what I have gathered, the System::Enum compiler error is something that
is supposed to be fixed in VS2005. I haven't verified this; I discovered
this morning that rebuilding the SDK in VS2005 is not going to be a walk in
the park either. It may not be that bad, but time is running short, and I
don't want to go through the trouble right now if it isn't going to solve
the problem.

So, I have a few questions for those of you who are willing to offer advice:

1. First, is there a solution/workaround to the compile problem I have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET 2003, am
I going to introduce more serious pain to SDK users out there who have
already moved on to VS 2005? What will they have to do to make it work?
3. If I go ahead and build/release with VS 2005, am I going to introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++ 6 for
awhile. I'm resigned to the idea of maintaining two flavors of the SDK. I
really don't want to go for three flavors..


Thank you A WHOLE LOT for reading this far. I eagerly await your opinion.

Suz
 
1) I don't understand what ever made you think you could box a native enum
in the first place in MEC++. Nor do I see why you want to there.

2) Maybe. It happened to me. I have ported a fair amount of MEC++ to C++/CLI
and it was quite a chore. We found that we had already shipping public,
managed API's written in MEC++ that could not be consumed/derived-from using
the C++/CLI syntax at all. I can send you a fairly succint repro of that
if you're interested but Microsoft confirmed that it was an old-syntax/new-syntax
incompatibility and that there was no way that a person writing C++/CLI was
going to be able to consume our already shipping MEC++ API. We had to break
compatibility to move forward. You don't want to be writing any new MEC++
code if you can avoid it.

3) Sure. You'll be desupporting them. You cannot consume a .NET 2 assembly
in something that you're building with the older toolset. And you cannot
produce anything but a .NET 2 assembly with the VS 2005 toolset.

3a) That's too bad. How old is VC 6 now? The late 1900's I believe...
I'm sure you have your reasons, but I really feel for you if you are pressured
to support native callers in VC6 and up and managed callers in .NET 1 and
up. That's rough. I would at least seek permission to forget about .NET
1.x clients of your API. Then you can forget about MEC++ and use C++/CLI
to implement your only managed API.

Bern McCarty
Bentley Systems, Inc.
Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached
critical mass
and I am now in the process of doing that.
Actually, the first release of this 'port' is be a simple rebuild of
the unmanaged C++ SDK in VS.NET. I have done this part already, using
VS.NET 2003. [This will allow VS.NET users to debug with our SDK
without having to manually pull in the VC++ 6.0 debug DLLs.]

The reason I chose to use VS.NET 2003 was that this is a seachange for
me, and all of the books and references I have acquired reference
Managed C++. I thought I could stand to learn the concepts with the
references I had and then switch to VS 2005/C++/CLI, knowing that this
will represent another (if smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for
the unmanaged SDK. I had planned for this to be done in VS 2005 using
C++/CLI, after a bit of a learning curve. It's a pedestrian approach,
I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application for
my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++ 7.1
compiler:
My SDK unmanaged class has the following declarations:

typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;
class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...
};

In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am
encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;
__box( device.FindCnx() ); // This line produces a
compiler error: error C3149: 'System::Enum' : illegal

// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no
compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at
runtime,
won't it?
}
}
From what I have gathered, the System::Enum compiler error is
something that is supposed to be fixed in VS2005. I haven't verified
this; I discovered this morning that rebuilding the SDK in VS2005 is
not going to be a walk in the park either. It may not be that bad,
but time is running short, and I don't want to go through the trouble
right now if it isn't going to solve the problem.

So, I have a few questions for those of you who are willing to offer
advice:

1. First, is there a solution/workaround to the compile problem I
have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET
2003, am
I going to introduce more serious pain to SDK users out there who have
already moved on to VS 2005? What will they have to do to make it
work?
3. If I go ahead and build/release with VS 2005, am I going to
introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++
6 for
awhile. I'm resigned to the idea of maintaining two flavors of the
SDK. I
really don't want to go for three flavors..

Thank you A WHOLE LOT for reading this far. I eagerly await your
opinion.

Suz
Click to expand...
 
1) I was being a dope, that's why. I got a little caught up in the whole
__box thing, that's all, thinking that everything has to be boxed. I have
completed the sample program with very little boxing actually required.

2) Our API is entirely unmanaged at this point. Are you saying that if we
compile it w/ VC++ 7.1, our VS 2003/C++/CLI end users will not be able to
consume it ?

3-3a) Thanks for your input. Aside from the (small) MC++ sample program,
and recompiling the unmanaged API with VC++ 7.1, not much has been invested
in VS.NET 2003. I think I can make the case for releasing these but not
maintaining them for future revisions, and jumping to C++/CLI for the new
managed API.

Suz.

Bern McCarty said:
1) I don't understand what ever made you think you could box a native
enum in the first place in MEC++. Nor do I see why you want to there.

2) Maybe. It happened to me. I have ported a fair amount of MEC++ to
C++/CLI and it was quite a chore. We found that we had already shipping
public, managed API's written in MEC++ that could not be
consumed/derived-from using the C++/CLI syntax at all. I can send you a
fairly succint repro of that if you're interested but Microsoft confirmed
that it was an old-syntax/new-syntax incompatibility and that there was no
way that a person writing C++/CLI was going to be able to consume our
already shipping MEC++ API. We had to break compatibility to move forward.
You don't want to be writing any new MEC++ code if you can avoid it.

3) Sure. You'll be desupporting them. You cannot consume a .NET 2
assembly in something that you're building with the older toolset. And
you cannot produce anything but a .NET 2 assembly with the VS 2005
toolset.

3a) That's too bad. How old is VC 6 now? The late 1900's I believe...
I'm sure you have your reasons, but I really feel for you if you are
pressured to support native callers in VC6 and up and managed callers in
.NET 1 and up. That's rough. I would at least seek permission to forget
about .NET 1.x clients of your API. Then you can forget about MEC++ and
use C++/CLI to implement your only managed API.

Bern McCarty
Bentley Systems, Inc.
Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached
critical mass
and I am now in the process of doing that.
Actually, the first release of this 'port' is be a simple rebuild of
the unmanaged C++ SDK in VS.NET. I have done this part already, using
VS.NET 2003. [This will allow VS.NET users to debug with our SDK
without having to manually pull in the VC++ 6.0 debug DLLs.]

The reason I chose to use VS.NET 2003 was that this is a seachange for
me, and all of the books and references I have acquired reference
Managed C++. I thought I could stand to learn the concepts with the
references I had and then switch to VS 2005/C++/CLI, knowing that this
will represent another (if smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for
the unmanaged SDK. I had planned for this to be done in VS 2005 using
C++/CLI, after a bit of a learning curve. It's a pedestrian approach,
I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application for
my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++ 7.1
compiler:
My SDK unmanaged class has the following declarations:

typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;
class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...
};

In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am
encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;
__box( device.FindCnx() ); // This line produces a
compiler error: error C3149: 'System::Enum' : illegal

// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no
compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at
runtime,
won't it?
}
}
From what I have gathered, the System::Enum compiler error is
something that is supposed to be fixed in VS2005. I haven't verified
this; I discovered this morning that rebuilding the SDK in VS2005 is
not going to be a walk in the park either. It may not be that bad,
but time is running short, and I don't want to go through the trouble
right now if it isn't going to solve the problem.

So, I have a few questions for those of you who are willing to offer
advice:

1. First, is there a solution/workaround to the compile problem I
have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET
2003, am
I going to introduce more serious pain to SDK users out there who have
already moved on to VS 2005? What will they have to do to make it
work?
3. If I go ahead and build/release with VS 2005, am I going to
introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++
6 for
awhile. I'm resigned to the idea of maintaining two flavors of the
SDK. I
really don't want to go for three flavors..

Thank you A WHOLE LOT for reading this far. I eagerly await your
opinion.

Suz
Click to expand...
Click to expand...
 
end users will not be able to consume it ?

No. I'm saying that it is very easy to unwittingly create a managed API in
MEC++ that is simply incompatible with C++/CLI clients. There is absolutely
nothing in any document anywhere that I've seen that warns you away from
that danger and we fell right into the trap. My advice is to forget about
MEC++ and .NET 1.x if at all possible. .NET 2 is hardly new. Heck, .NET
3 is already out and .NET 3.5 will be out by the end of the year. All I'm
saying is that you should question whether or not your clients that desire
a managed API really need to execute in the old .NET 1.x environment. It
seems to me that clients clamoring for a managed API over a native system
are clients that are clamoring for something new, and .NET 1.x ain't new.

-Bern
1) I was being a dope, that's why. I got a little caught up in the
whole __box thing, that's all, thinking that everything has to be
boxed. I have completed the sample program with very little boxing
actually required.

2) Our API is entirely unmanaged at this point. Are you saying that
if we compile it w/ VC++ 7.1, our VS 2003/C++/CLI end users will not
be able to consume it ?

3-3a) Thanks for your input. Aside from the (small) MC++ sample
program, and recompiling the unmanaged API with VC++ 7.1, not much has
been invested in VS.NET 2003. I think I can make the case for
releasing these but not maintaining them for future revisions, and
jumping to C++/CLI for the new managed API.

Suz.

1) I don't understand what ever made you think you could box a
native enum in the first place in MEC++. Nor do I see why you want
to there.

2) Maybe. It happened to me. I have ported a fair amount of MEC++ to
C++/CLI and it was quite a chore. We found that we had already
shipping public, managed API's written in MEC++ that could not be
consumed/derived-from using the C++/CLI syntax at all. I can send you
a fairly succint repro of that if you're interested but Microsoft
confirmed that it was an old-syntax/new-syntax incompatibility and
that there was no way that a person writing C++/CLI was going to be
able to consume our already shipping MEC++ API. We had to break
compatibility to move forward. You don't want to be writing any new
MEC++ code if you can avoid it.

3) Sure. You'll be desupporting them. You cannot consume a .NET 2
assembly in something that you're building with the older toolset.
And you cannot produce anything but a .NET 2 assembly with the VS
2005 toolset.

3a) That's too bad. How old is VC 6 now? The late 1900's I
believe... I'm sure you have your reasons, but I really feel for you
if you are pressured to support native callers in VC6 and up and
managed callers in .NET 1 and up. That's rough. I would at least
seek permission to forget about .NET 1.x clients of your API. Then
you can forget about MEC++ and use C++/CLI to implement your only
managed API.

Bern McCarty
Bentley Systems, Inc.
Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached
critical mass
and I am now in the process of doing that.
Actually, the first release of this 'port' is be a simple rebuild of
the unmanaged C++ SDK in VS.NET. I have done this part already,
using
VS.NET 2003. [This will allow VS.NET users to debug with our SDK
without having to manually pull in the VC++ 6.0 debug DLLs.]
The reason I chose to use VS.NET 2003 was that this is a seachange
for me, and all of the books and references I have acquired
reference Managed C++. I thought I could stand to learn the concepts
with the references I had and then switch to VS 2005/C++/CLI,
knowing that this will represent another (if smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for
the unmanaged SDK. I had planned for this to be done in VS 2005
using C++/CLI, after a bit of a learning curve. It's a pedestrian
approach, I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application
for
my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++
7.1
compiler:
My SDK unmanaged class has the following declarations:
typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;
class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...
};
In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am
encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;
__box( device.FindCnx() ); // This line produces a
compiler error: error C3149: 'System::Enum' : illegal
// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no
compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at
runtime,
won't it?
}
}
From what I have gathered, the System::Enum compiler error is
something that is supposed to be fixed in VS2005. I haven't verified
this; I discovered this morning that rebuilding the SDK in VS2005 is
not going to be a walk in the park either. It may not be that bad,
but time is running short, and I don't want to go through the
trouble
right now if it isn't going to solve the problem.
So, I have a few questions for those of you who are willing to offer
advice:

1. First, is there a solution/workaround to the compile problem I
have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET
2003, am
I going to introduce more serious pain to SDK users out there who
have
already moved on to VS 2005? What will they have to do to make it
work?
3. If I go ahead and build/release with VS 2005, am I going to
introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++
6 for
awhile. I'm resigned to the idea of maintaining two flavors of the
SDK. I
really don't want to go for three flavors..
Thank you A WHOLE LOT for reading this far. I eagerly await your
opinion.

Suz
Click to expand...
Click to expand...
Click to expand...
 
Ah. That is what I hoped you were saying!
Thanks for all your help.
S

Bern McCarty said:
end users will not be able to consume it ?

No. I'm saying that it is very easy to unwittingly create a managed API in
MEC++ that is simply incompatible with C++/CLI clients. There is
absolutely nothing in any document anywhere that I've seen that warns you
away from that danger and we fell right into the trap. My advice is to
forget about MEC++ and .NET 1.x if at all possible. .NET 2 is hardly new.
Heck, .NET 3 is already out and .NET 3.5 will be out by the end of the
year. All I'm saying is that you should question whether or not your
clients that desire a managed API really need to execute in the old .NET
1.x environment. It seems to me that clients clamoring for a managed API
over a native system are clients that are clamoring for something new, and
.NET 1.x ain't new.

-Bern
1) I was being a dope, that's why. I got a little caught up in the
whole __box thing, that's all, thinking that everything has to be
boxed. I have completed the sample program with very little boxing
actually required.

2) Our API is entirely unmanaged at this point. Are you saying that
if we compile it w/ VC++ 7.1, our VS 2003/C++/CLI end users will not
be able to consume it ?

3-3a) Thanks for your input. Aside from the (small) MC++ sample
program, and recompiling the unmanaged API with VC++ 7.1, not much has
been invested in VS.NET 2003. I think I can make the case for
releasing these but not maintaining them for future revisions, and
jumping to C++/CLI for the new managed API.

Suz.

1) I don't understand what ever made you think you could box a
native enum in the first place in MEC++. Nor do I see why you want
to there.

2) Maybe. It happened to me. I have ported a fair amount of MEC++ to
C++/CLI and it was quite a chore. We found that we had already
shipping public, managed API's written in MEC++ that could not be
consumed/derived-from using the C++/CLI syntax at all. I can send you
a fairly succint repro of that if you're interested but Microsoft
confirmed that it was an old-syntax/new-syntax incompatibility and
that there was no way that a person writing C++/CLI was going to be
able to consume our already shipping MEC++ API. We had to break
compatibility to move forward. You don't want to be writing any new
MEC++ code if you can avoid it.

3) Sure. You'll be desupporting them. You cannot consume a .NET 2
assembly in something that you're building with the older toolset.
And you cannot produce anything but a .NET 2 assembly with the VS
2005 toolset.

3a) That's too bad. How old is VC 6 now? The late 1900's I
believe... I'm sure you have your reasons, but I really feel for you
if you are pressured to support native callers in VC6 and up and
managed callers in .NET 1 and up. That's rough. I would at least
seek permission to forget about .NET 1.x clients of your API. Then
you can forget about MEC++ and use C++/CLI to implement your only
managed API.

Bern McCarty
Bentley Systems, Inc.
Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached
critical mass
and I am now in the process of doing that.
Actually, the first release of this 'port' is be a simple rebuild of
the unmanaged C++ SDK in VS.NET. I have done this part already,
using
VS.NET 2003. [This will allow VS.NET users to debug with our SDK
without having to manually pull in the VC++ 6.0 debug DLLs.]
The reason I chose to use VS.NET 2003 was that this is a seachange
for me, and all of the books and references I have acquired
reference Managed C++. I thought I could stand to learn the concepts
with the references I had and then switch to VS 2005/C++/CLI,
knowing that this will represent another (if smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for
the unmanaged SDK. I had planned for this to be done in VS 2005
using C++/CLI, after a bit of a learning curve. It's a pedestrian
approach, I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application
for
my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++
7.1
compiler:
My SDK unmanaged class has the following declarations:
typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;
class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...
};
In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am
encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;
__box( device.FindCnx() ); // This line produces a
compiler error: error C3149: 'System::Enum' : illegal
// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no
compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at
runtime,
won't it?
}
}
From what I have gathered, the System::Enum compiler error is
something that is supposed to be fixed in VS2005. I haven't verified
this; I discovered this morning that rebuilding the SDK in VS2005 is
not going to be a walk in the park either. It may not be that bad,
but time is running short, and I don't want to go through the
trouble
right now if it isn't going to solve the problem.
So, I have a few questions for those of you who are willing to offer
advice:

1. First, is there a solution/workaround to the compile problem I
have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET
2003, am
I going to introduce more serious pain to SDK users out there who
have
already moved on to VS 2005? What will they have to do to make it
work?
3. If I go ahead and build/release with VS 2005, am I going to
introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++
6 for
awhile. I'm resigned to the idea of maintaining two flavors of the
SDK. I
really don't want to go for three flavors..
Thank you A WHOLE LOT for reading this far. I eagerly await your
opinion.

Suz
Click to expand...
Click to expand...
Click to expand...
 
2) Our API is entirely unmanaged at this point. Are you saying that if we
compile it w/ VC++ 7.1, our VS 2003/C++/CLI end users will not be able to
consume it ?
Click to expand...

Effectively, that is true, yes. Managed Extensions for C++ were very buggy,
had loader lock race conditions, etc, when used in a mixed assembly, and
these problems cannot be overcome with the .NET 1.x runtime.

You should not use VC7 with /clr. With freely available VC++ 2005, there's
no reason for anyone to use VC7 anymore, even for native code.
 
Uh. I just re-read your reply here, and Mr Voigt's.

Please explain how one could "unwittingly" create a managed API in MEC++?
Or does the unwittingly refer to the incompatibility with C++/CLI ?

The API today is unmanaged. It is not compiled with /clr.

I am getting the message that I should abandon VS.NET 2003.
My debate at this moment is whether to release what I have (unmanaged API)
that is built w/2003 or hold off and not release anything until it is all
under 2005.

S.


Bern McCarty said:
end users will not be able to consume it ?

No. I'm saying that it is very easy to unwittingly create a managed API in
MEC++ that is simply incompatible with C++/CLI clients. There is
absolutely nothing in any document anywhere that I've seen that warns you
away from that danger and we fell right into the trap. My advice is to
forget about MEC++ and .NET 1.x if at all possible. .NET 2 is hardly new.
Heck, .NET 3 is already out and .NET 3.5 will be out by the end of the
year. All I'm saying is that you should question whether or not your
clients that desire a managed API really need to execute in the old .NET
1.x environment. It seems to me that clients clamoring for a managed API
over a native system are clients that are clamoring for something new, and
.NET 1.x ain't new.

-Bern
1) I was being a dope, that's why. I got a little caught up in the
whole __box thing, that's all, thinking that everything has to be
boxed. I have completed the sample program with very little boxing
actually required.

2) Our API is entirely unmanaged at this point. Are you saying that
if we compile it w/ VC++ 7.1, our VS 2003/C++/CLI end users will not
be able to consume it ?

3-3a) Thanks for your input. Aside from the (small) MC++ sample
program, and recompiling the unmanaged API with VC++ 7.1, not much has
been invested in VS.NET 2003. I think I can make the case for
releasing these but not maintaining them for future revisions, and
jumping to C++/CLI for the new managed API.

Suz.

1) I don't understand what ever made you think you could box a
native enum in the first place in MEC++. Nor do I see why you want
to there.

2) Maybe. It happened to me. I have ported a fair amount of MEC++ to
C++/CLI and it was quite a chore. We found that we had already
shipping public, managed API's written in MEC++ that could not be
consumed/derived-from using the C++/CLI syntax at all. I can send you
a fairly succint repro of that if you're interested but Microsoft
confirmed that it was an old-syntax/new-syntax incompatibility and
that there was no way that a person writing C++/CLI was going to be
able to consume our already shipping MEC++ API. We had to break
compatibility to move forward. You don't want to be writing any new
MEC++ code if you can avoid it.

3) Sure. You'll be desupporting them. You cannot consume a .NET 2
assembly in something that you're building with the older toolset.
And you cannot produce anything but a .NET 2 assembly with the VS
2005 toolset.

3a) That's too bad. How old is VC 6 now? The late 1900's I
believe... I'm sure you have your reasons, but I really feel for you
if you are pressured to support native callers in VC6 and up and
managed callers in .NET 1 and up. That's rough. I would at least
seek permission to forget about .NET 1.x clients of your API. Then
you can forget about MEC++ and use C++/CLI to implement your only
managed API.

Bern McCarty
Bentley Systems, Inc.
Greetings,

My group has an SDK that was developed 5 years ago with VC++ 6.
Over the last years, the requests for a VS.NET SDK has reached
critical mass
and I am now in the process of doing that.
Actually, the first release of this 'port' is be a simple rebuild of
the unmanaged C++ SDK in VS.NET. I have done this part already,
using
VS.NET 2003. [This will allow VS.NET users to debug with our SDK
without having to manually pull in the VC++ 6.0 debug DLLs.]
The reason I chose to use VS.NET 2003 was that this is a seachange
for me, and all of the books and references I have acquired
reference Managed C++. I thought I could stand to learn the concepts
with the references I had and then switch to VS 2005/C++/CLI,
knowing that this will represent another (if smaller) seachange.

The plan for the next phase of my SDK includes a managed wrapper for
the unmanaged SDK. I had planned for this to be done in VS 2005
using C++/CLI, after a bit of a learning curve. It's a pedestrian
approach, I know.

Perhaps these plans are misguided; read on.

Today I started creating a Managed C++ winforms sample application
for
my
unmanaged C++ SDK.
In the process, I stumbled upon what I think is a bug in the VC++
7.1
compiler:
My SDK unmanaged class has the following declarations:
typedef enum
{
CNX_NONE = -2
, CNX_UNKNOWN = -1
, CNX_USB = 0
, CNX_SER
} eCommType;
class SDKobject
{
...
public:
eCommType FindCnx();
BOOL CnxReady();
...
};
In my Managed C++ sample code, I would like to do something like the
following (not exactly, but this represents the errors I am
encountering):

void WinformSample::Form1::Connect( void )
{
SDKobject device;
__box( device.FindCnx() ); // This line produces a
compiler error: error C3149: 'System::Enum' : illegal
// use of managed type 'System::Enum'; did you forget a '*'?

if ( __box( device.CnxReady() ) ) // This line produces no
compiler
error
{
}
else
{
device.FindCnx(); // This produces no
compiler error, but it will create garbage-collection problems at
runtime,
won't it?
}
}
From what I have gathered, the System::Enum compiler error is
something that is supposed to be fixed in VS2005. I haven't verified
this; I discovered this morning that rebuilding the SDK in VS2005 is
not going to be a walk in the park either. It may not be that bad,
but time is running short, and I don't want to go through the
trouble
right now if it isn't going to solve the problem.
So, I have a few questions for those of you who are willing to offer
advice:

1. First, is there a solution/workaround to the compile problem I
have
illustrated in VS.NET 2003?
2. If I find a solution to #1 and release the SDK built w/ VS.NET
2003, am
I going to introduce more serious pain to SDK users out there who
have
already moved on to VS 2005? What will they have to do to make it
work?
3. If I go ahead and build/release with VS 2005, am I going to
introduce a
world of hurt to VS.NET 2003 users?
3a. I am already planning to continue to maintain the SDK w/ VC++
6 for
awhile. I'm resigned to the idea of maintaining two flavors of the
SDK. I
really don't want to go for three flavors..
Thank you A WHOLE LOT for reading this far. I eagerly await your
opinion.

Suz
Click to expand...
Click to expand...
Click to expand...
 
STG said:
Uh. I just re-read your reply here, and Mr Voigt's.

Please explain how one could "unwittingly" create a managed API in MEC++?
Or does the unwittingly refer to the incompatibility with C++/CLI ?
Click to expand...

Managed Extensions for C++ will crash. There's no way to avoid the loader
lock bug except upgrading to .NET 2.0, and then it's only natural to use
C++/CLI which is much better though out, well supported, and is the future
path for C++ in .NET.
The API today is unmanaged. It is not compiled with /clr.
Click to expand...

Then I'm confused why you are talking about boxing and so forth. Unmanaged
code doesn't have a concept of "boxing".
I am getting the message that I should abandon VS.NET 2003.
My debate at this moment is whether to release what I have (unmanaged API)
that is built w/2003 or hold off and not release anything until it is all
under 2005.
Click to expand...

Unmanaged C++ code will upgrade very easily between VS2002/VS2003/VS2005.
Managed code not so.
 
I encountered my boxing confusion while creating a very small managed MEC++
sample application to demonstrate consuming my *unmanaged* API from a
managed app.

My plan at the moment is to just release my unmanaged API, built with VS'03,
just to get it out the door.
I'm not sure if I will let the managed sample go with it. It is a winform
app, and I have discovered that I dislike winforms ... I could replace it
with a managed console app; not fancy but it will get the job done. If I
don't do this, it is inevitable that a customer will call or write asking
for help and I'll end up doing it anyway.

Then I'll migrate to VS2005 right away. I will build a managed wrapper for
the API and take the time I need to know what the heck I'm doing mucking
around in here.

Thanks for helping and being a sounding board. I work in a small hardware
company; I am the only host software engineer.. That can be good and bad.
This week it would have been better to have a few people to help me grope
through this.

Suz.
 
Back
Top