1

这个问题之前已经在 SO 上被问过，例如这里和这里。这种情况是，人们想在他们的应用程序中使用 COM 组件，而不必在机器上注册 COM 组件。这是通过添加两个清单文件来完成的，一个到客户端，一个到服务器，操作系统的并行功能负责其余部分。现在，当所有 Dll 都在同一个文件夹中时，这可以正常工作。

在我的特定场景中，我试图让旧版 .net 2.0 dll 访问 4.0 dll。我们不想更改 2.0 dll，通过上述方法，我能够做到这一点。但是，如果 4.0 dll 位于可执行文件（2.0 dll）的子文件夹中。并行执行开始时找不到 4.0 dll。我目前正在调用 win32 API 并创建一个新的 ActivationContext 传递清单文件。我使用 ProcMon 并看到 dll 正在可执行目录中查找，而不是在清单中指定的路径中查找。正如上面的链接也证明，.net 似乎只知道清单中的 ClrClass 并忽略了为私有程序集查找提供的 AssemblyLocation ，这是非常不幸的！

无论如何，上述链接中的解决方法是 GAC 和 AssemblyResolve。如果可能的话，我不想通过 GAC，而且 AssemblyResolve 对我不起作用，因为我必须在无法加载 4.0 dll 的 2.0 dll 中订阅它。

是否有任何类型的黑客让应用程序认为它暂时位于其他地方以便找到 dll？

我也知道使用 service(web, windows) 来启用 2.0 应用程序调用 4.0 应用程序。除了上述三种之外，任何其他可能性都会被理解。

4

1 回答 1

1

您应该能够在查找程序集时使用<probing>您的元素让app.configCLR 在子文件夹中查找。因此，如果您的 4.0 DLL 在子文件夹中，ComDll您的 app.config 将如下所示：

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="ComDll"/>
      </assemblyBinding>
   </runtime>
</configuration>

私有路径必须是您的 EXE 的子文件夹，这应该适用于您的情况。

于 2015-08-11T17:09:57.397 回答