使用 XCOPY 部署动态加载程序集及其依赖项答案

【问题标题】：Dynamically loading assemblies and their dependents using XCOPY deployment使用 XCOPY 部署动态加载程序集及其依赖项
【发布时间】：2009-10-06 12:26:28
【问题描述】：

我有一个动态加载应用程序的应用程序加载器。应用程序是一个程序集，其所有依赖项都位于一个文件夹中。使用 XCOPY 部署，我可以通过复制/删除文件夹来添加/删除应用程序。为了便于标准的 .NET 程序集绑定，我将应用程序文件夹复制到加载程序的 bin 下。我在配置文件中设置了探测 privatePath，一切都像一个魅力。

应用程序使用框架，即共享程序集作为依赖项。

现在我有一个要求，即每个应用程序都必须能够使用自己的框架版本。

当我在 GAC 中安装框架版本时，这可以完美运行，并且将程序集的不同版本加载到默认的 AppDomain 中就好了。

现在我想回到我的 XCOPY 解决方案并将正确的框架版本复制到其相应的应用程序文件夹中，但解决方案会中断。

引用其框架的第一个应用程序工作正常，第二个应用程序抱怨找不到程序集并且清单不匹配。

就好像 .NET 加载程序在第一次与“privatePath”中的文件夹匹配后停止探测并且不再查看。

关于如何获得与使用 GAC 时相同的行为有什么想法吗？还有什么我可以在配置代码库中指定的吗？（请不要使用绝对文件路径）。

韩币，米歇尔

【问题讨论】：

标签： .net dynamic xcopy assembly.load

【解决方案1】：

根据this关于组件的文章：

您还应该记住，CLR 浏览预定的顺序探测期间的目录。给定一个 MyAssemblies 的 privatePath 值， CLR 现在将探测程序集在下面命名为 MyLibrary 顺序：

C:/Apps/MyLibrary.DLL
C:/Apps/MyLibrary/MyLibrary.DLL
C:/Apps/MyAssemblies/MyLibrary.DLL
C:/Apps/MyAssemblies/MyLibrary/MyLibrary.DLL
C:/Apps/MyLibrary.EXE
C:/Apps/MyLibrary/MyLibrary.EXE
C:/Apps/MyAssemblies/MyLibrary.EXE
C:/Apps/MyAssemblies/MyLibrary/MyLibrary.EXE

文件路径的顺序，其中程序集文件的 CLR 探针是很重要，因为探测过程一旦 CLR 找到程序集就停止具有正确文件名的文件。如果你部署一个应用程序 MyLibrary.dll 的一个版本 ApplicationBase 目录和第二个子目录中的版本 MyAssemblies，哪个 DLL 文件将 CLR 负载？您应该看到 CLR 将在 ApplicationBase 目录，因为始终是搜索的第一个目录在探测过程中由 CLR 执行。

更新：

查看this 的帖子。它处理的问题或多或少与您遇到的相同。

【讨论】：

谢谢。此外，如果 privatePath 包含多个文件夹，则在搜索 privatePath 中的第一个文件夹后，无论是否找到版本，探测似乎都会停止。我重申这个问题：是否可以让探测过程在与引用程序集相同的文件夹中查找被引用程序集？如果没有，是否可以让探测过程在 privatePath 中指定的所有文件夹中搜索匹配的程序集版本？ kr，米歇尔。

【解决方案2】：

如果您使用 Assembly.LoadFrom 来加载您在这些文件夹中找到的所有程序集，您将会有更多的运气。

这会改变探测行为并允许运行时在本地搜索到最初加载程序集的位置，以便找到它的引用。不过，您将在程序集级别获得框架版本共享。

即：

应用“a”加载，导致框架 v1.02 加载。
应用“b”加载，导致框架 v1.01 加载。
App 'c' 加载，链接到 Framework v1.02，并简单地重用 App 'a' 加载后加载的代码。

也就是说 - 如果您没有显式加载程序集，此解决方案可能没有用。

在这种情况下 - 我会采用 Yannick M. 提到的答案中的解决方案 - 挂钩 AssemblyResolve 事件；在您开始加载应用程序时存储一些静态状态，以便您的事件处理程序知道正在加载哪个应用程序；如果任何程序集无法解析，您可以查看此状态以确定它应该查找的位置并从那里加载程序集。

【讨论】：