views:

93

answers:

2

Previously we had software in MFC (VC6), VB6 and C# applications that needed to call the same engine written in C++ (and MFC). The engine required C++ for speed. At the time we decided to use COM as the interface because all three could use it with the least issues in marshalling, etc.

Our MFC application is now deprecated and we have recently decided to dump VB6, so what we've got left is C#.

We can just leave the COM engine as-is, but it would be nice to get away from COM registration, etc., and have a managed interface to work with. COM registration occasionally causes support issues if there is something wrong with the person's machine.

Is it possible to have a dll with the existing unmanaged C++/MFC, and a .NET front end interface?

A: 

C++/CLI can do both.

Joshua
+1  A: 

You can have a C++/CLI DLL that uses MFC classes internally. One nice advantage to mixed-mode DLL creation with C++/CLI is that you can use native C++ just about anywhere within the DLL (following the C++/CLI rules) and "it just works".

The goal here, however, should be to provide nice, clean, managed wrappers that can be called from your C# application.

That being said - you'll most likely want to avoid using MFC for any user interface elements. Though possible to host MFC content in C# and vice versa, it often is problematic - you're better off just encapsulating the C++ engine (time critical operations) and legacy code in nice, clean managed wrappers using C++/CLI.

Reed Copsey
Walter Williams
http://www.functionx.com/cppcli/index.htm - For the most part, once you learn the "CLI" part, it's the same as C++ for the MFC issues...
Reed Copsey
I was actually wondering more about the practical issues - should I create an MFC dll and add /clr or create a Class Library and tag the unmanaged code, etc. Thanks for that link too.
Walter Williams