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 is开发者_如何学Csues 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?
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.
C++/CLI can do both.
精彩评论