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

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

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 ?

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.

"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