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

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" <Bern@xxxxxxxxxxxxxxxxx> wrote in message
news:5951ef06325f68c94a7009ddd464@xxxxxxxxxxxxxxxxxxxxxxx

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





.

Relevant Pages