EEFileLoadException при использовании классов С# в С++ (приложение win32)

Ответ 1

Проблема заключалась в том, где были расположены библиотеки DLL.

• C:\DLLs\managed.dll
• C:\DLLs\wrapper.dll
• C:\EXE\my.exe

Я подтвердил это, скопировав файл manage.dll в c:\exe, и он работал без проблем. По-видимому, CLR не будет искать управляемые DLL на пути неуправляемой DLL и будет искать его только там, где находится исполняемый файл. (или в GAC).

По причинам, в которые не стоит входить, это структура, в которой я нуждаюсь, а это означало, что мне нужно было дать CLR руку, расположенную в управляемой dll. См. Следующий код:

AssemblyResolver.h:

/// <summary>
/// Summary for AssemblyResolver
/// </summary>
public ref class AssemblyResolver
{
public:

static Assembly^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )
{
    Console::WriteLine( "Resolving..." );

    Assembly^ thisAssembly = Assembly::GetExecutingAssembly();
    String^ thisPath = thisAssembly->Location;
    String^ directory = Path::GetDirectoryName(thisPath);
    String^ pathToManagedAssembly = Path::Combine(directory, "managed.dll");

    Assembly^ newAssembly = Assembly::LoadFile(pathToManagedAssembly);
    return newAssembly;
}

};

Wrapper.cpp:

#include "AssemblyResolver.h"

extern "C" __declspec(dllexport) IMyObject* CreateMyObject(void)
{
    try
    {
        AppDomain^ currentDomain = AppDomain::CurrentDomain;
        currentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver::MyResolveEventHandler );

        return new CMyWrapper( );
    }
    catch(System::Exception^ e)
    {
        System::Console::WriteLine(e->Message);

        return NULL;
    }
}

Ответ 2

Первая проблема - убедиться, что тип Debugger установлен в смешанный. Затем вы получаете полезные исключения.

Ответ 3

Для вашего родного приложения, использующего dll смешанного режима (ваш EXE), измените ** "Тип отладчика" на "Смешанный" режим. (Перейдите к Свойствам проекта → Свойства конфигурации → Отладка)

Есть несколько других моментов (которые могут не относиться к вам), но по моему опыту они могут вызвать проблемы.  - В окнах 8 (с более жесткой безопасностью) попробуйте запустить VS как администратор.  - Убедитесь, что для конфигурации x86 вы используете двоичные файлы x86.  - Следите за проверкой StrongName, если ваши сборки С#, которые вы используете в управляемом С++, как подписанные, также рассмотрите возможность подписи и dll смешанного режима.

Надеюсь, это поможет.

Ответ 4

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

I.e., ваш MyResolveEventHandler должен быть в форме:

static Assembly^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )
{
    Console::WriteLine( "Resolving..." );

    String^ assemblyName = args->Name;

    // Strip irrelevant information, such as assembly, version etc.
    // Example: "Acme.Foobar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
    if( assemblyName->Contains(",") ) 
    {
        assemblyName = assemblyName->Substring(0, assemblyName->IndexOf(","));
    }

    Assembly^ thisAssembly = Assembly::GetExecutingAssembly();
    String^ thisPath = thisAssembly->Location;
    String^ directory = Path::GetDirectoryName(thisPath);
    String^ pathToManagedAssembly = Path::Combine(directory, assemblyName );

    Assembly^ newAssembly = Assembly::LoadFile(pathToManagedAssembly);
    return newAssembly;
}

Ответ 5

Я получал исключение С++ EEFileLoadException, которое многократно загружало iisexpress.exe во время отладки приложения ASP.NET MVC. Стек вызовов и исключение С++ не были очень полезны, помогая мне выявить проблему.

Посмотрев прямо на адрес указателя, указанный в исключении С++, я в конце концов обнаружил библиотечную строку, которая указывала на то, что старая версия больше не используется. Это, в свою очередь, было связано с устаревшей записью в моем файле web.config:

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Security.OAuth" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly> </assemblyBinding> </runtime>

Я обновил различные библиотеки безопасности Microsoft.Own через NuGet до версии 4.0.30319, но эта строка в конфиге давала указание серверу перенаправлять вызовы на версию 3.0.1.0, которая теперь больше не является частью моего проекта. Обновление конфигурации изменило мои проблемы.

Ответ 6

При запуске в собственном проекте отладчика С++, который использует управляемую dll с С++, вы можете получить это исключение. Когда VS2010 поймает его и ваше приложение после того, как некоторые исключения в цепочке будут прерваны, вы можете попробовать использовать фильтр исключений (Menu | Debug | Excpetion), чтобы отключить все исключения С++. Вы все равно увидите это исключение в выводе, но ваше приложение не прервется