Managed C++

I’ve started experimenting with Managed C++ again. I never really considered it a serious tool because generally I like the C# language better, and my previous experiments with trying to take an existing C++ app and turn it into a Managed C++ app have been painful and generally fruitless.

But somewhere at the PDC, I saw something (vague huh) that said you could make just part of a C++ application managed. So I loaded up a large MFC app, selected a single random file in the middle of it and turned on the /clr switch. I also had to turn off /ZI (reduced it to /Zi), and turn off the runtime checks, but once that was done, it compiled, linked, and still ran.

Next test was to add a call to some managed code into my C++ and that worked perfectly as well.

This is great for consuming .NET objects from C++ since you can just use them without having to do any tricks at all… but I’m starting to see that trying to mix C++ and Managed C++ in the same application is not going to be easy.

One of the problems is that even though I can put a C++ object in a .cpp file, I can’t expose that object via a header file, since the syntax required would be illegal in standard C++. The Managed C++ object would only be accessible if you wrapped it in some standard C++ object and the rest of the code used that instead.

Another problem is that reflection doesn’t work the way it does for a completely managed app. You can’t really reflect against a mixed binary – Assembly.Load barfs trying to load it. This is too bad, since if it worked, you’d be able to write unit tests to test an unmanaged C++ application in Managed C++ and then use NUnit or something like it to run the tests. NUnit depends on reflection to find tests, so it won’t work in this case.