0
votes

I have an old MFC code that I would like to call from my managed C# WPF .Net application. For wrapping the native code, I discovered that I had the options to either use 1) P/Invoke 2) C++/CLI or 3) COM.

But I have another concern. I read that you have to build MFC Extension DLL whenever it’s going to include classes derived from the MFC. Also, that the calling side of this DLL must be an MFC environment, which I think means that this DLL is not workable inside my managed code.

In my application, I have classes that derive from base MFC classes. I use the document view architecture, and my Doc, View , MainFrame, App classes are derived from MFC classes. Does this mean that I have no other option than to build an MFC Extension DLL, and that there is no way to use this DLL in my managed application. Any suggestions how to get around this problem?

1
I am considering rewriting the native code without MFC. Will it help? I want to be able to compile it to a dll, and call that dll from from my C# .Net application. - user2654449
Pinvoke is very unlikely to be useful, it cannot call C++ methods. COM tends to be off the deep end since your existing code is not COM-callable. Which leaves C++/CLI, usually the best choice. All of the normal MFC hoopla about extension DLLs apply, no difference. - Hans Passant
@HansPassant, but arent MFC Extension DLLs unusable when referenced from managed code? I am trying to determine if I need to get rid of the MFC portion inside my native code, and rewrite it as a Windows application using WinAPI - user2654449
C++/CLI can call any native C++ code. It does not matter that it uses the MFC framework. - Hans Passant

1 Answers

1
votes

Why don't you encapsulate your MFC code in a MFC ActiveX Project and use Interoperability to call it from your managed code application? Seems the easiest solution to me.