0

这是我的场景：

我正在为我的项目使用 Microsoft AddIn 框架，以便拥有一个不错的插件架构。我还有一个自定义 API，我将其编译为 dll。宿主应用程序和所有插件都需要引用这个 api。显然，当使用这个框架时，所有的插件都必须在 AddIns 目录中它们自己的目录中。

根据我目前的经验，必须将单个插件引用的任何程序集放在单个插件的目录中，否则将找不到它导致异常。在我的情况下，每个插件都引用 API，因此必须在其目录中包含该 dll。这意味着我有一堆似乎不必要的 API dll 副本。我宁愿只有一个地方可以放置所需的程序集（例如应用程序根目录下的 lib 文件夹），主机和所有插件都可以找到它们。这可能吗？也许以不同的方式加载插件（appdomain？）将允许他们查看主机应用程序目录。我对 MAF 比较陌生，所以任何关于如何做这个组织的建议都会有所帮助。

4

2 回答 2

1

在 .Net 中不能做的一件事是在加载后从 AppDomain 中卸载 DLL。如果不同的插件使用具有不同 API 签名的不同版本的 3rd 方 DLL，您可能想要这样做（例如）。MAF 可以通过为每个 AddIn 实例化一个新的 AppDomain 来支持这一点 - 每个 AppDomain 都有自己的第 3 方 DLL 版本。

这就是为什么您需要在每个 AddIn 文件夹中拥有一个单独的第 3 方 DLL 副本：允许您将每个 AddIn 与其他 AddIn 中的实现或依赖项的更改隔离开来。

然而，答案也部分取决于 .Net 如何解决程序集依赖项以及您如何激活插件。

.Net 将在其中使用类型（不包括 GAC）的 AppDomain 的 BaseDirectory 和 PrivateBinPath 中探测程序集依赖项。

当您激活插件时，它是在 AppDomain 内完成的。如果您不指定一个，您将为每个 AddIn 获得一个新的 AppDomain，并且该 AppDomain 将 BaseDir 设置为 AddIn 文件夹 - 因此将在那里找到第 3 方 DLL。

如果您确实指定了 AppDomain，则将在该 appdomain 的 BaseDir 和 PrivateBinPath 中查找依赖程序集。这可以完全忽略 AddIn 文件夹中的任何第 3 方 DLL！

请记住，MAF 也有关于 AddIn 目录结构的时髦规则 - 它甚至禁止 AddIn 视图 DLL 在 AddIn 目录本身中。

我得出的结论是，为了支持 AddIn 的所有不同激活模式，AddIn 文件夹中应该只有一个DLL。我们正在更新我们的构建过程，以将所有依赖的 DLL 合并到 AddIn dll 中，包括附属程序集、Sgen 序列化 DLL 以及第 3 方 DLL。

考虑到这一点，也许您应该考虑解决构建过程中的“重复 DLL”问题？

于 2016-03-14T14:48:20.227 回答
0
  1. 如果将“通用”程序集部署到 GAC 是一种选择，它应该允许任何加载程序集绑定
  2. 如果您正在部署一个独立的应用程序，您可以尝试将您的公共程序集与 exe 放在同一文件夹中，或者将探测映射添加到其位置：

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

查看更多详细信息http://www.thescarms.com/dotnet/Assembly.aspx

于 2011-03-17T06:39:38.607 回答