通过 COM/Interop 与通过 .NET 应用程序调用 .NET 程序集时，引用的程序集是否使用不同的加载上下文？

Question

我使用 COM Interop 从 VB6 应用程序调用托管代码，该应用程序本身在创建新的 AppDomain 后随后从另一个托管程序集调用代码。这个新的 AppDomain 实际上实例化了正在使用的对象的实例。

为了让这个更容易理解，这些是播放器：

• VB6 应用程序： LegacyApp.exe
• 包含所有 .NET 程序集中使用的接口信息的程序集： MeatyInterfaces.dll
• COM 互操作可见的 .NET 程序集： InteropAssembly.dll
  • 此程序集直接引用 MeatyInterfaces.dll
• InteropAssembly.dll 使用的程序集： MeatyImplementations.dll
  • 此程序集直接引用 MeatyInterfaces.dll，并实现这些接口
  • 通过实现“MeatyImplementations.ExampleImplementation”实现接口“MeatyInterfaces.IExampleInterface”

为了简化该过程，本质上我们创建一个 AppDomain 并实例化 ExampleImplementation新的 AppDomain 在由 LegacyApp.exe 调用的 InteropAssembly.dll 代码中：

AppDomainSetup domainSetup = GetExampleSetupInfo();
AppDomain domain = AppDomain.CreateDomain(domainSetup.ApplicationName, AppDomain.CurrentDomain.Evidence, domainSetup);
ObjectHandle handle = domain.CreateInstance("MeatyImplementations.dll", "MeatyImplementations.ExampleImplementation");

一旦我们有了这个句柄，我们尝试解开它并将其转换为 IExampleInterface，ExampleImplementation 实现了它。

MeatyInterfaces.IExampleInterface initializer = (MeatyInterfaces.IExampleInterface) handle.Unwrap();

这会引发以下异常：

Exception: "System.InvalidCastException"
Message: "Unable to cast transparent proxy to type 'MeatyInterfaces.IExampleInterface'"

奇怪的是，如果我们运行这段确切的代码，但从托管（.NET）应用程序开始，它工作得很好。

以下是我所知道的：

• 我知道可以在两个上下文中加载程序集：Load 和 LoadFrom，并且后者对 DLL 的位置敏感。
• 我知道将对象从一个加载上下文转换到另一个加载上下文似乎是此问题的最常见原因（事实上，这是我能够找到相当详尽的搜索的唯一原因）
• 我知道，如果我重写 AssemblyResolve 事件正如这里推荐的（http://west-wind.com/weblog/posts/601200.aspx），它解决了问题，这进一步向我表明（尽管我没有实质性证据）InteropAssembly。当以上述方式使用时，dll 必须在与 MeatyImplementations.dll 不同的加载上下文中加载 MeatyInterfaces.dll。

所以这就是我不明白的地方...如果有人可以提供说明，我将不胜感激：

我不明白的是为什么加载上下文会有所不同，具体取决于我是否通过 VB6 使用 InteropAssembly.dll应用程序（使用 COM Interop）与 .NET 应用程序，或者加载上下文的整个概念是否一直只是一个转移注意力的问题，而他的修复只是巧合地解决了我的问题。

Answer 1

我找到了答案：

我错误地查看了 Fusion Log：

InteropAssembly.dll 正在 LoadFrom 上下文中加载，但这不是问题所在。问题是，当 InteropAssembly.dll 尝试加载 MeatyInterfaces.dll 时，它找不到它：MeatyInterfaces.dll 位于 InteropAssembly.dll 所在的 bin 文件夹中，但它并没有在那里寻找它：它正在寻找在 LegacyApp.exe 的应用程序路径中。

.NET 应用程序的工作基本上是巧合：这些程序集作为构建过程的一部分添加到 .NET 应用程序的 bin 文件夹中，因此它在它正在检查的文件夹中拥有所需的所有依赖项。

我看到的导致我进入加载上下文路径的异常基本上是一个巧合：加载依赖项失败直到第一次使用它才触发异常，这恰好是发生转换的地方：这引发了在大多数情况下，该异常似乎是由不匹配的加载上下文引起的。

F7U12

是的，这就是原因：我现在已经学到了困难的方法，尽管可以通过 COM Interop 从调用应用程序的路径（或 GAC）以外的位置加载程序集，但程序集的依赖项仍然需要在应用程序的路径中。噢。