0

我们目前正在为某些软件开发插件。我们决定使用 .NET 进行开发，即使应用程序是用某种本地语言编写的。由于在 .NET 中直接创建外部接口存在一些问题，我们决定在 C++/CLI 中构建一个桥接 DLL，它会进行一些基本的初始化，然后加载我们的托管程序集并从中创建一个用户控件。

在加载项 .ini 文件中，C++/CLI DLL 按名称引用，因此应用程序将从那里加载它。但是，.NET DLL 只是从 C++/CLI DLL 引用（作为托管引用），因此导出的类型可用。然而，在此设置中，应用程序在加载 .NET DLL 时会崩溃。

我们很快发现我们可以只订阅AppDomain.AssemblyResolve事件以从 C++/CLI DLL 所在的同一目录加载 .NET 程序集，因此问题本身就解决了。

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

4

2 回答 2

4

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

Fuslogvw.exe 和诊断 .NET 程序集绑定问题

当然，还有用于分析未找到文件问题的通用工具：

进程监视器

于 2010-09-21T15:46:56.703 回答
1

当非托管 EXE 启动进程时，程序集的探测路径变得有点不可预测。仅仅因为它加载了一个 C++/CLI DLL，可能是通过 LoadLibrary 或 SetDllDirectory，不会以任何方式影响 CLR 的探测路径。

但这只是猜测。当您查看 Fuslogvw.exe 生成的输出时，无需猜测。它准确地向您显示正在探测的内容以及应用了哪些策略。您可以使用 app.exe.config 文件（探测元素）或通过 AssemblyResolve 解决问题。

于 2010-09-21T15:51:37.937 回答