This is in regards to the previous question about "mixing MFC doc/view modules with .NET Winforms components." I would like to know the reasons to your answer:
The general strategy is to not mix them. While I guess you could possibly hack and slash enough to get an MFC library to display inside a Windows Form, the effort would huge and a waste of time. My advice would be to rewrite from scratch if you're going the Windows Form route.
The basic ones at least, please. I have to wrap in .NET a huge MFC C++ library that could take months to re-write in C#. Thanks a lot.
You're right, I should expand on my answer. The original question was asked by someone who wanted to directly mix MFC doc/views with .NET and the way it was phrased, it sounded like a straight MFC doc/view application without any COM/OLE capabilities. In that case, you're not going to have much luck at all mixing everything together as you're missing the COM bridge between them.
If your MFC library does support an ActiveX interface, or you can wrap it on one (which may be a great deal of work on it's own), you stand a chance of getting that library into a .NET Windows Forms application. .NET does a pretty decent job of handling ActiveX/COM component interoperability, so you'd get to save your library and still use it.
This was first published in February 2004