Pourquoi voyons-nous une exception ModuleLoadExceptionHandlerException lors du test unitaire

Question

Nous avons un ensemble en mode mixte qui contient à la fois VC++ (en utilisant MFC) et des classes C++/CLI. Il s'agit d'une DLL d'extension MFC et est chargé dans notre exécutable MFC à l'exécution et tout fonctionne bien.

Quand nous arrivons à l'unité tester les classes non gérées là-dedans d'un autre assemblage C++/CLI, nous voyons l'exception suivante à chaque fois que nous essayons de créer une instance (via nouveau) d'une classe non gérée:

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() 

Cela ressemble à un échec de chargement de l'ensemble par le coureur d'essai (Gallio.Echo dans ce cas).

J'ai également créé une petite application de console C++/CLI et j'ai essayé de faire la même chose. Je peux créer correctement une instance d'une classe ref contenue dans l'assembly, mais lorsque j'essaie de créer une nouvelle classe, je reçois la même exception.

Des idées?

EDIT

je vais poster le code de l'application de la console qui a éclaté ici, mais je l'ai recompilé et il fonctionne maintenant! Ici, il est:

#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; 
} 

Lorsque j'utilise son code est un test unitaire:

#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); 
} 

Il casse. C'est le seul test dans l'ensemble de test.

L'application de console est une application de console CLR où l'assembly de test se trouve dans une bibliothèque de classes CLR. Pour autant que je sache, ils utilisent les mêmes options de compilation. Pourquoi travaille-t-on et pas un?

Answer 1

Votre ensemble de test unitaire est-il également C++/CLI?

(modifié en fonction des nouvelles informations)

Intriguant. Je me demande si cela pourrait être dû à un constructeur statique géré échouant dans la DLL en mode mixte? Ou quelque chose qui va de travers dans la construction d'une variable native globale?

Je trouve mention du même problème dans ce numéro Connect: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=316549

mais pas de solution ou d'un diagnostic correct, j'ai peur.