C++ and C# interoperability

[Bruce Schechter]

Background: I have nearly two years of experience with C# and the .NET
framework, as well as a fair amount of C experience from many years ago, but
no C++ background (until about two months ago.) Now, I am helping a team
develop an application with a UI based on C# and business logic coded in
C++. The choice of C++ is because the team has several key elements of the
business logic already coded in VC++ (from pre- .NET tools.)



Ideally I'd like to compile the final project altogether within vs.net 2003,
in which I'd combine the C# UI project with the C++ business layer project
resulting in one .NET executable. But after reading up on these topics in
MSDN, I've run into some issues about which I need advice regarding these
two points:



1.) It looks like the only way to combine the C++ code into the .NET project
is to convert it into "managed code" (which involves quite a bit of
modifications to the C++ source, like tagging each class with the __gc
modifier, etc.) Is that a correct understanding/assessment? Sounds like a
tedious job on the C++ side, and would totally "break" our ability to
re-use the C++ in future non-.NET projects, correct? Is there a mechanism
to write C++ code that can be conditionally compiled as either managed or
not managed?



2.) I gather that we could compile the C++ modules into one DLL and then
access it from the .NET project using some kind of wrapper?? I frankly don'
t fully understand what this means. Could someone recommend a link to a
good article on this topic?



Which of these paths makes the most sense, if we want to keep the C++ code
in standard (as close as possible to ANSI standard) format for potential
portability? Am I missing any other good approaches to the overall
strategy?



Thanks,

Bruce

 

[Jesse McGrew]

Bruce Schechter wrote:
[...]

1.) It looks like the only way to combine the C++ code into the .NET project
is to convert it into "managed code" (which involves quite a bit of
modifications to the C++ source, like tagging each class with the __gc
modifier, etc.) Is that a correct understanding/assessment? Sounds like a
tedious job on the C++ side, and would totally "break" our ability to
re-use the C++ in future non-.NET projects, correct? Is there a mechanism
to write C++ code that can be conditionally compiled as either managed or
not managed?

To access the same classes directly from C#, yes, you would have to do
that. There is a #define that you can check to see if you're compiling
managed code, but I can't think of it offhand... and the number of
differences between what unmanaged and managed classes are allowed to do
would make this a nightmare, IMO.

2.) I gather that we could compile the C++ modules into one DLL and then
access it from the .NET project using some kind of wrapper?? I frankly don'
t fully understand what this means. Could someone recommend a link to a
good article on this topic?

This is what I'd suggest. Here's an article about it:
http://www.ondotnet.com/pub/a/dotnet/2004/03/29/mcpp_part3.html

Jesse

 

[Gary Chang]

Hi Bruce,

Additionally, you can make your C++ business logic code into COM
components, them use COM Interop to access them from C# applications:

COM Interop Tutorials
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/
vcoricominteroptutorial.asp

COM Interop Part 1 Sample
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cssample/ht
ml/vcsamCOMInterOpSample.asp

Advanced COM Interop
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconadvancedcominterop.asp


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Bruce Schechter]

Gary and Jesse,

Thanks very much for your answers and links. Although I have more analysis
to do, it tentitively looks to me like the best solution in my case is to
keep our C++ code independent of the .NET framework, compile it into a COM
component, and then let vs.net take care of building the wrapper around it
for interop with my C# UI.

Thanks again,
-- Bruce

 

[Bruce Schechter]

Gary,

I would like to try the COM interop approach described in this article.
But I need help with one more element of that approach... Can you point me
to an article to explain how I can take my set of (unmanaged, legacy) C++
classes and create a COM object from them? (All my experience so far with
Microsoft tools has been with the .NET framework. I have no comprehension
of what kind of effort is required to create a COM object.)

Thanks, Bruce

 

[Nat Wells]

The easiest solution might be to write the UI in managed c++ (instead of
c#).
Then you can combine everything into a single project. Compile the legacy
c++ code using /clr (no source changes), and "it just works".
nwells

 

[Gary Chang]

Hi Bruce,

After re-considering your problem carefully, I recognized that the best
approach for your case is used the IJW to interop between the unmanaged and
managed code, I agree with the Jesse and Nat's opinion.

The COM interop is for use of calling OLE Automation compatible COM
components(such as some Office automation components), which it appears not
your scenario.

However, the IJW(It Just Works) is a managed C++-specific feature which
enables flat APIs and COM APIs to be used directly, it is for use of
wrapping complex unmanaged flat APIs(or wrapping unmanaged flat APIs which
changing frequently during developing) and calling IDL based COM
components, so I think it is the proper approach to your case.


Please refer to the following detail document:

An Overview of Managed/Unmanaged Code Interoperability
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/manunmancode.asp


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Bruce Schechter]

Nat,

Thanks for the message. That is a very interesting prospect.

I will give that a try.

cheers, Bruce