Ładowanie trybu mieszanego C++/CLI .dll (i zależności) dynamicznie z niezarządzanego C++

Question

Mam zarządzany zestaw C++, który ładuję dynamicznie w niezarządzanej aplikacji C++ za pośrednictwem standardowego wywołania LoadLibrary(). Zarządzany zestaw w C++ ma zależności od kilku zarządzanych (C#) zespołów. Wszystko działało dobrze, dopóki nie przeniosłem wszystkich zarządzanych zestawów do podkatalogu aplikacji niezmienionej. Dla ilustracji

• zarządzane C++ DLL (MyCoolDll.dll)

  • zależności od DotNetDll1.dll
  • zależności od DotNetDll2.dll

• Niezarządzane C++ app (MyCoolApp .exe)

  • Ładunki MyCoolDll.dll poprzez LoadLibrary ("MyCoolDll.dll")

ten działa dobrze, aż przeniesiono MyCoolDll.dll, DotNetDll1.dll & DotNetDll2.dll do/someSubDirectory (kod w MyCoolApp. exe został zaktualizowany do LoadLibrary ("someSubDirectory/MyCooldll.dll")

Zgaduję, gdy załadowany jest MyCoolDll.dll, próbuje znaleźć DotNetDll1.dll i DotNetDll2.dll w katalogu roboczym, zamiast katalogu to mieszka w.

Jak mogę powiedzieć MyCoolDll.dll jego zależności żyć w subdir Ektoria? Jest to biblioteka działająca wewnątrz niezarządzanej aplikacji, więc nie sądzę, że mogę to określić w app.config czy cokolwiek innego?

Answer 1

CLR jest ładowany w niezwykły sposób w tym scenariuszu przez thunk że kompilator wstrzykiwany podczas kompilacji natywnej eksport dla __declspec (dllexport). Takie postępowanie jest w porządku, po prostu nie jest szczególnie szybkie.

CLR wyruszy na poszukiwania pliku .config, aby zainicjować podstawowe AppDomain. I będzie szukał MyCoolApp.exe.config, niezależnie od tego, że to wcale nie jest zarządzany plik wykonywalny. Możesz użyć <probing> element, aby dodać podkatalogi do wyszukiwania złożeń.

Answer 2

Myślę, że to, czego szukasz, to niestandardowy przelicznik złożenia. Musiałem użyć jednego do zrobienia tego, co myślę, że próbujesz zrobić - chciałem zlokalizować niektóre biblioteki DLL w folderze, który nie znajdował się w drzewie początkowego niezarządzanego pliku DLL (który ostatecznie załadował kod zarządzany).

Krok 1 jest, aby funkcję można zadzwonić do skonfigurowania rozpoznawania nazw:

void PrepareManagedCode() 
{ 
    // Set up our resolver for assembly loading 
    AppDomain^ currentDomain = AppDomain::CurrentDomain; 
    currentDomain->AssemblyResolve += gcnew ResolveEventHandler(currentDomain_AssemblyResolve); 
} // PrepareManagedCode() 

wtedy rozpoznawania. Przykład ten ma globalny ourFinalPath który w danym przypadku byłby dodatkowy Folder uzywasz:

/// <summary> 
/// This handler is called only when the CLR tries to bind to the assembly and fails 
/// </summary> 
/// <param name="sender">Event originator</param> 
/// <param name="args">Event data</param> 
/// <returns>The loaded assembly</returns> 
Assembly^ currentDomain_AssemblyResolve(Object^ sender, ResolveEventArgs^ args) 
{ 
    sender; 

    // If this is an mscorlib, do a bare load 
    if (args->Name->Length >= 8 && args->Name->Substring(0, 8) == L"mscorlib") 
    { 
     return Assembly::Load(args->Name->Substring(0, args->Name->IndexOf(L",")) + L".dll"); 
    } 

    // Load the assembly from the specified path 
    String^ finalPath = nullptr; 
    try 
    { 
     finalPath = gcnew String(ourAssemblyPath) + args->Name->Substring(0, args->Name->IndexOf(",")) + ".dll"; 
     Assembly^ retval = Assembly::LoadFrom(finalPath); 
     return retval; 
    } 
    catch (...) 
    { 
    } 

    return nullptr; 
}