Почему мы видим ModuleLoadExceptionHandlerException при модульном тестировании - PullRequest
Новая
       14

Почему мы видим ModuleLoadExceptionHandlerException при модульном тестировании

4 голосов
/ 16 июля 2009

У нас есть сборка смешанного режима, которая содержит классы VC ++ (с использованием MFC) и C ++ / CLI. Это dll-расширение MFC, которое загружается в наш исполняемый файл MFC во время выполнения и все работает хорошо.

Когда мы приходим к юнит-тестированию неуправляемых классов из другой сборки C ++ / CLI, мы видим следующее исключение каждый раз, когда пытаемся создать экземпляр (через новый) неуправляемого класса: 

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

Это похоже на ошибку при загрузке сборки тестовым прогоном (в данном случае Gallio.Echo).

Я также создал небольшое консольное приложение C ++ / CLI и попробовал эффективно то же самое. Я могу правильно создать экземпляр класса ref, содержащийся в сборке, но когда я пытаюсь создать новый класс без изменений, я получаю то же исключение.

Есть идеи?

РЕДАКТИРОВАТЬ

Я собирался опубликовать код консольного приложения, который сломался здесь, но я перекомпилировал его, и теперь он работает! Вот оно: 

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

Когда я использую его код, это юнит-тест: 

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

Это ломается. Это единственный тест в тестовой сборке.

Консольное приложение представляет собой консольное приложение CLR, где тестовая сборка выполняется в библиотеке классов CLR. Насколько я могу судить, они используют одинаковые параметры компилятора. Почему один работает, а другой нет?

1 Ответ

1 голос
/ 16 июля 2009

Является ли ваша модульная тестовая сборка также C ++ / CLI?

(отредактировано на основе новой информации)

Интригующий. Интересно, может ли это быть из-за сбоя управляемого статического конструктора в DLL смешанного режима? Или что-то пошло не так при создании глобальной нативной переменной?

Я обнаружил упоминание той же проблемы в этой проблеме Connect: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=316549

но, боюсь, нет решения или правильного диагноза.

...