Why do we see ModuleLoadExceptionHandlerException exception during unit testing

We have a mixed-mode assembly that contains both VC ++ (using MFC) and C ++ / CLI classes. This is a MFC Extension DLL and is loaded into the MFC executable at runtime, and everything works fine.

When we come to the unit test unmanaged classes there from another C ++ / CLI assembly, we see the following exception every time we try to create an instance (through a new) unmanaged class:

Exception System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> <CrtImplementationDetails>.ModuleLoadExceptionHandlerException: A nested exception occurred after the primary exception that caused the C++ module to fail to load. ---> System.Runtime.Serialization.SerializationException: Serialization error. at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr function, Void* cookie) at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr , Void* ) at <CrtImplementationDetails>.LanguageSupport.InitializeDefaultAppDomain(LanguageSupport* ) in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 518 at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* ) in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 721 at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 875 --- End of inner exception stack trace --- at <CrtImplementationDetails>.ThrowNestedModuleLoadException(Exception innerException, Exception nestedException) at <CrtImplementationDetails>.ThrowNestedModuleLoadException(Exception , Exception ) at <CrtImplementationDetails>.LanguageSupport.Cleanup(LanguageSupport* , Exception innerException) in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 841 at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 883 at .cctor() in f:\dd\vctools\crt_bld\self_x86\crt\src\mstartup.cpp:line 922 --- End of inner exception stack trace --- at MSMContactDataTests.LoadUnknownItemTest() 

It looks like an inability to load the assembly with a test runner (Gallio.Echo in this case).

I also created a small console application in C ++ / CLI and tried the same thing effectively. I can correctly create an instance of the ref class contained in the assembly, but when I try to create a new class without changes, I get the same exception.

Any ideas?

EDIT

I was going to publish the console code of the application here, but I recompiled it, and now it works! Here he is:

 #include "stdafx.h" using namespace System; #include "SCacheAssignment.h" int main(array<System::String ^> ^args) { Console::WriteLine(L"Hello World"); SCacheAssignment* assignment = new SCacheAssignment(NULL, false); assignment->id = 2; Console::WriteLine(L"Hello World 2 " + assignment->id); return 0; } 

When I use its code, this is unit test:

 #include "stdafx.h" #include "PBSMSDataStoreUnitTests2.h" #include "SCacheAssignment.h" using namespace PBSMSDataStoreUnitTests2; void Class1::SomeTest() { Console::WriteLine(L"Hello World"); SCacheAssignment* assignment = new SCacheAssignment(NULL, false); assignment->id = 2; Console::WriteLine(L"Hello World 2 " + assignment->id); } 

It breaks. This is the only test in the test build.

The console application is a CLR console application, where the test assembly is in the CLR class library. As far as I can tell, they use the same compiler options. Why does one work and the other not?

+4
source share
1 answer

Is your unit test assembly also C ++ / CLI?

(edited based on new information)

Intriguing. I wonder if this could be due to the fact that the managed static constructor does not work in a mixed-mode DLL? Or was something going into building a global variable?

I found a mention of the same problem in this Connect problem: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=316549

but no solution or correct diagnosis, I'm afraid.

+1
source

All Articles