Robin Davies - 2005-11-17

MSVC 7.1 user (also 8.0), currently running CPPUnit 1.11.4 (but CPPUnit 1.10.2 doesn't seem any better).

I'm a veteran professional MSVC programmer, but I seem to be missing some essential concept wrt/ the cppunit .lib files.

I would like to add CPPunit tests to various DLLs (mostly COM dlls, so linking as an EXE is *not* an option). The documentation seems to suggest that DLLs must link with CPPUNITD_DLL.DLL (for debug builds). This actually does work for my test class, although I get compiler warnings about non-dll export declarations of std::string in one of the CPPUNIT base classe (rightly so). And when I run the project using DllPluginTesterd_dll.exe, I get runtime trashed-heap exceptions because of std::strings passed across a DLL boundary. Interestingly, if I ignore the errors, my test classes appear, and are runnable. But unhandled exceptions during startup of the test plugin runner is not going to fly in my organization.

But, frankly, exporting C++ classes from a DLL in a Microsoft environment isn't something that sane programmers do. Just C classes, and memory managment across a DLL export call must be carefully handled. As I see it, the _dll.lib libraries are not usable for this reason, and are probably not fixable. My guess is that MSVC 6.1 might have done this without warnings, and trahsed the heap anway. MSVC 7.1 gives very legitimate warnings and errors in response to this abuse.

When I switch to the non-DLL library (CPPUNITD.DLL), and remove the CPPUNIT_DLL #define, everything compiles and links properly, but my test doesn't show up in the list of tests in DllPluginRunnerD.exe. 

How am I supposed to do this?

Am I right to think that the Win32 DLL plugin system is badly broken? And is anyone planning on fixing it?

Here's the way I think it should work:

Debug DLLs using the Multithreaded Debug DLL libraries should reference a *static* library CPPUNITD_DLL.LIB containing CPPUNIT compiled code, compiled with /MDD options. Debug DLLs using the Multi-threaded Debug non-DLL runtime should link against CPPUNITD.LIB, containing *static* object files for CPPUNIT, linked with /MD options. I can't think of any reason why DLLs should have to link against one interface or the other (unless nobody has produced a narrow C interface to the DLL registries). xxx(I'm guess the latter is the case).

Either way, CPPUNIT C++ code should be statically linked, not dynamically linked.

The DllMain implementation in CPPUNIT_PLUGIN_IMPLEMENT() is also very uncool. This implementation is invasive, and will *never* be the right thing to do, as far as I can see.

Open to suggestions on better ways to run tests against DLLs (COM dlls, particularly).

Open to contributing to fix this mess if somebody's in charge of the madness.