即使组件在同一目录中，也找不到组装参考

Question

我们目前正在为某些软件开发一个加载项。即使应用程序是用某种母语编写的，我们也决定在.NET中开发。由于有一些问题直接在.NET中创建外部接口，因此我们决定在C ++/CLI中构建一个桥梁DLL，该桥梁可以进行一些基本的初始化，然后加载我们的托管组件并从中创建用户控件。

在一个加载程序.INI文件中，C ++/CLI DLL由名称引用，因此该应用程序将从那里加载。但是，.NET DLL仅从C ++/CLI DLL（作为托管参考）引用，因此可以使用导出类型。在此设置中，Howerver，应用程序崩溃了加载.NET DLL。

我们很快发现我们可以订阅 AppDomain.AssemblyResolve 从同一目录中加载.NET组件的事件，从而解决了问题本身。

实际的问题是：即使加载程序与引用它的组件相同的目录，也为什么没有找到.NET DLL？我一直期望加载程序集将首先查看相同的目录，而不仅仅是当前工作目录。如果这样更改其工作目录，为什么可执行文件会找到一个程序集呢？或者，如果通过加载C ++/CLI组件（而不是纯托管应用程序）来调用CLR，情况是否有所不同？

Answer 1

我建议您使用 fuslogvw.exe 用于分析此类问题：

fuslogvw.exe和诊断.NET组装绑定问题

而且，当然，是分析未发现文件问题的通用工具：

过程监视器

Answer 2

当不管理的EXE启动该过程时，组件的探测路径会变得有些不可预测。仅仅因为它加载了C ++/CLI DLL，也许是通过LoadLibrary或setDlldirectory的 不是 以任何方式影响CLR的探测路径。

但这只是猜测。当您查看fuslogvw.exe产生的输出时，无需猜测。它准确地显示了正在探索的内容和应用哪些政策。您可以使用app.exe.config文件（探测元素）或通过“汇编”来解决问题。