[ACCEPTED]-EEFileLoadException when using C# classes in C++(win32 app)-managed-c++

The problem was where the DLLs were located.

• c:\dlls\managed.dll
• c:\dlls\wrapper.dll
• c:\exe\my.exe

I 9 confirmed this by copying managed.dll into 8 c:\exe and it worked without issue. Apparently, the 7 CLR won't look for managed DLLs in the path 6 of the unmanaged DLL and will only look 5 for it where the executable is. (or in the 4 GAC).

For reasons not worth going into, this 3 is the structure I need, which meant that 2 I needed to give the CLR a hand in located 1 the managed dll. See code below:

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

The first issue is to make sure the Debugger 2 type is set to mixed. Then you get useful 1 exceptions.

For you native application consuming the 13 mixed mode dll (Your EXE), change the **"Debugger 12 Type" to "Mixed" mode. (Go to Project Properties 11 -> Configuration Properties -> Debugging)

There 10 are some other points (which might not be 9 relevant to you) but in my experience they 8 could cause issues. - On windows 8 (with 7 tighter security) please try launching your 6 VS as admin. - Make sure that for x86 configuration 5 you are using x86 binaries. - Watch for 4 StrongName verification, if your C# assemblies 3 which you are consuming in Managed C++ as 2 signed, please consider signing the mixed 1 mode dll too.

Hope this would help.

In case anyone else stumbles upon this question, and 5 you are using a dynamic assembly name: make 4 sure you are stripping the assembly name, it 3 may contain version, culture and other content 2 that you may not use.

I.e., your MyResolveEventHandler 1 should be in the form of:

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

I was getting the C++ EEFileLoadException 17 thrown a lot by iisexpress.exe during debugging 16 of an ASP.NET MVC application. The call 15 stack and C++ exception itself were not 14 terribly helpful in helping me pin down 13 the problem.

After looking directly at the 12 pointer address given in the C++ exception 11 I eventually discovered a library string 10 which was pointing to an old version no 9 longer in use. This in turn was due to 8 an out-of-date entry in my web.config file:

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

I 7 had upgraded various Microsoft.Own security 6 libraries via NuGet to version 4.0.30319 5 but this line in the config was instructing 4 the server to redirect calls to version 3 3.0.1.0, which was now no longer part of 2 my project. Updating the config resovled 1 my problems.