I\'ve set up a project in Visual Studio 2010 to write unit tests against an existing MFC DLL. I\'m using a single-header unit test framework, and linked to the MFC DLL\'s li
You should check that both the EXE and the DLL are dynamically linked with the same debug CRT (/MDd
compiler option). Make sure that also other settings like _HAS_ITERATOR_DEBUGGING
are the same for both the EXE and the DLL.
(A shortcut could be to just use const wchar_t*
instead of std::wstring
at the class interface, and just build a std::wstring
from the raw pointer inside constructor's body).
EDIT: You confirmed that CRT mismatch (i.e. EXE built with /MD
vs. DLL built with /MDd
) was the problem. The fact is that the same class name std::wstring
means two different classes in debug builds (/MDd
) and in release builds (/MD
). In fact, in debug builds there can be additional mechanics inside the class implementation to help debugging; this mechanics can introduce inefficiencies, so it's removed in release builds. So, the internal structure of debug build's std::wstring
is different from release build's std::wstring
(e.g. if you try to print the raw sizeof
of std::wstring
instances, you can find different numbers in release builds and debug builds). So, the EXE built with /MD
was expecting release-build's std::wstring
; instead the DLL built with /MDd
was expecting debug-build's std::wstring
: there is a mismatch between these two expectations (one module is expecting class X
but the other module is giving class Y
) and so you have a crash.