动态地从非托管的C加载混合模式C ++ / CLI .dll文件（和依赖性）++
我有一个托管C ++组件，我在动态的非托管C ++应用程序通过一个标准的LoadLibrary（）调用加载。托管C ++组件有几个管理（C＃）组件的依赖关系。一切工作正常，直到我把所有的托管程序的unmananged应用程序的一个子目录中。为了说明：
I have a managed C++ assembly I'm loading dynamically in an unmanaged c++ application through a standard LoadLibrary() call. The managed C++ assembly has dependencies on several more managed (C#) assemblies. Everything worked fine until I moved all the managed assemblies to a subdirectory of the unmananged application. To illustrate:
-
托管C ++ .DLL（MyCoolDll.dll）
Managed C++ .dll (MyCoolDll.dll)
- 取决于DotNetDll1.dll
- 取决于DotNetDll2.dll
非托管的C ++应用程序（MyCoolApp.exe）
Unmanaged C++ app (MyCoolApp.exe)
- 通过调用LoadLibrary加载MyCoolDll.dll（MyCoolDll.dll）
这工作得很好，直到我感动MyCoolDll.dll，DotNetDll1.dll和放大器; DotNetDll2.dll到/ someSubDirectory（在code在MyCoolApp.exe进行了更新，调用LoadLibrary（someSubDirectory / MyCooldll.dll）
This worked fine, until I moved MyCoolDll.dll, DotNetDll1.dll & DotNetDll2.dll to /someSubDirectory (the code in MyCoolApp.exe was updated to LoadLibrary("someSubDirectory/MyCooldll.dll")
我猜当MyCoolDll.dll被加载时，它试图找到DotNetDll1.dll和DotNetDll2.dll在工作目录中，而不是目录它生活在
I'm guessing when MyCoolDll.dll is loaded, it's trying to find DotNetDll1.dll and DotNetDll2.dll in the working directory, instead of the directory it lives in.
我怎么能告诉MyCoolDll.dll它的依赖生活在一个子目录？它是一个非托管的应用程序中运行的图书馆，所以我不认为我可以在一个app.config或任何指定此？
How can I tell MyCoolDll.dll its dependencies live in a subdirectory? It's a library running inside of an unmanaged app, so I don't think I can specify this in an app.config or anything?
在CLR得到在这种情况下一个不寻常的方式加载，通过一个thunk的编制本地出口为__declspec（dllexport）的编译时注入。这样做是好的，只是不是特别快。
The CLR gets loaded in an unusual way in this scenario, through a thunk that the compiler injected when compiling the native export for __declspec(dllexport). Doing this is fine, it just isn't particularly fast.
CLR将出去打猎的config文件来初始化主AppDomain中。而将寻找MyCoolApp.exe.config，无论这是不是一个托管可执行的。您可以使用 ＆LT ;探测＆GT; 元素添加子目录来搜索组件
The CLR will go out hunting for a .config file to initialize the primary AppDomain. And will look for MyCoolApp.exe.config, regardless that this is not a managed executable at all. You can use the <probing> element to add subdirectories to search for assemblies.