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
8  1613 
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
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**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsoft .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
>>>>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**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsoft .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
Ah. That is what I hoped you were saying!
Thanks for all your help.
S
"Bern McCarty" <Be**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsoft .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**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsof t.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
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.
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" <Be**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsoft .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**@newsgroups.nospamwrote in message
news:59**************************@msnews.microsof t.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
"STG" <stg@go-spam-yourselfwrote in message
news:eI**************@TK2MSFTNGP03.phx.gbl...
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 ?
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.
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.nospamwrote in message
news:%2****************@TK2MSFTNGP03.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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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,...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
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...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| | |
