473,856 Members | 1,634 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

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


Apr 11 '07 #1
8 1648

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

Apr 11 '07 #2
STG
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" <Be**@newsgroup s.nospamwrote in message
news:59******** *************** ***@msnews.micr osoft.com...
>
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


Apr 12 '07 #3
>>>>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" <Be**@newsgroup s.nospamwrote in message
news:59******** *************** ***@msnews.micr osoft.com...
>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
compatibilit y 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.FindCn x(); // 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

Apr 12 '07 #4
STG
Ah. That is what I hoped you were saying!
Thanks for all your help.
S

"Bern McCarty" <Be**@newsgroup s.nospamwrote in message
news:59******** *************** ***@msnews.micr osoft.com...
>
>>>>>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" <Be**@newsgroup s.nospamwrote in message
news:59******* *************** ****@msnews.mic rosoft.com...
>>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
compatibili ty 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.FindC nx(); // 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
illustrate d 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


Apr 12 '07 #5
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 ?
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.
Apr 12 '07 #6
STG
Uh. I just re-read your reply here, and Mr Voigt's.

Please explain how one could "unwittingl y" 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" <Be**@newsgroup s.nospamwrote in message
news:59******** *************** ***@msnews.micr osoft.com...
>
>>>>>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" <Be**@newsgroup s.nospamwrote in message
news:59******* *************** ****@msnews.mic rosoft.com...
>>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
compatibili ty 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.FindC nx(); // 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
illustrate d 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


Apr 13 '07 #7

"STG" <stg@go-spam-yourselfwrote in message
news:eI******** ******@TK2MSFTN GP03.phx.gbl...
Uh. I just re-read your reply here, and Mr Voigt's.

Please explain how one could "unwittingl y" create a managed API in MEC++?
Or does the unwittingly refer to the incompatibility with C++/CLI ?
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.
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.
Unmanaged C++ code will upgrade very easily between VS2002/VS2003/VS2005.
Managed code not so.
Apr 13 '07 #8
STG
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.
"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
>
>>
The API today is unmanaged. It is not compiled with /clr.

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.

Unmanaged C++ code will upgrade very easily between VS2002/VS2003/VS2005.
Managed code not so.

Apr 13 '07 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
2659
by: Beach Potato | last post by:
Dear Y'all: I'm about to start porting a big old project written in anscient version of Delphi to something more stable, robust, supportable and maybe even portable. Since I haven't seriously touched C for large implementations, I'm seeking advice on what to use for development. My ultimate goal is to spend as less time on it as possible. I'll be writing it in Windows 32-bit environment, probably Win2000 or Win98. Planning to use a...
47
4557
by: ship | last post by:
Hi We need some advice: We are thinking of upgrading our Access database from Access 2000 to Access 2004. How stable is MS Office 2003? (particularly Access 2003). We are just a small company and this is a big decision for us(!) It's not just the money it's committing to an new version of Access!
7
1976
by: J.Marsch | last post by:
I don't know whether this is the appropriate place to give product feedback, but here goes: I would love to see some kind of diagnostic to let me know when implicit boxing has occurred. We have had a few instances where one developer or another was working on code, and did not realize that by passing their value type to a method that accepted an object parameter (or in many cases, a delegate).
2
2522
by: Edward Diener | last post by:
In C++ an overridden virtual function in a derived class must have the exact same signature of the function which is overridden in the base class, except for the return type which may return a pointer or reference to a derived type of the base class's return type. In .NET the overridden virtual function is similar, but an actual parameter of the function can be a derived reference from the base class's reference also. This dichotomy...
6
1134
by: Eddie Paz | last post by:
I have a program written in MFC. I'm at the point where I need to start working on the major release (tons of new features needed - new fiscal year budget and all-). I'm looking into vc++.net since I figure that I need to buy the bullet already and get into the .net thing. I'm concerned, however, with the syntax change in Whidbey. I feel that if I start coding now, I'm going to have to update all my "old" syntax to the new. My deadline...
1
9670
by: David Van D | last post by:
Hi there, A few weeks until I begin my journey towards a degree in Computer Science at Canterbury University in New Zealand, Anyway the course tutors are going to be teaching us JAVA wth bluej and I was wondering if anyone here would be able to give me some tips for young players such as myself, for learning the language. Is this the best Newsgroup for support with JAVA?
8
1531
by: george.leithead | last post by:
Hi all, I'm looking for some advice on how best to achitect the following requirement. I'm basically writing a Fantasy Football (FF) Web site, and would like to have it fully OO and have it using as much inheritance, base classes, common methods, etc as possible. My biggest headache that I cant get my head around is how to handle
8
2213
by: WebSnozz | last post by:
I have an application written in C that does a lot of low level stuff. It does a lot of things like casting from void*'s. I want to create a new GUI for it in either C# or MC++, but reuse the existing code. The options I've considered so far: 1. Create a new MC++ GUI project and add the *.c files to them and mark them with pragma unamanged. However, the /clr option does not compile *.c files, so I rename them to *.cpp, and now they...
232
13415
by: robert maas, see http://tinyurl.com/uh3t | last post by:
I'm working on examples of programming in several languages, all (except PHP) running under CGI so that I can show both the source files and the actually running of the examples online. The first set of examples, after decoding the HTML FORM contents, merely verifies the text within a field to make sure it is a valid representation of an integer, without any junk thrown in, i.e. it must satisfy the regular expression: ^ *?+ *$ If the...
0
9919
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, weíll explore What is ONU, What Is Router, ONU & Routerís main usage, and What is the difference between ONU and Router. Letís take a closer look ! Part I. Meaning of...
0
9763
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10699
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10787
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
5762
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5960
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4578
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4176
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3203
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.