以下是我的情景：
我正在为我的项目使用Microsoft AddIn Framework，以便拥有一个不错的插件架构。我还有一个自定义API，我编译成一个DLL。主机应用程序和所有插件都需要引用此API。显然，使用此框架时，所有addin必须位于AddIns目录内的自己的目录中。
根据我的经验，到目前为止，单个插件引用的任何程序集都必须放在单独的addin目录中，否则将无法找到导致异常的程序集。在我的情况下，每个插件都引用API，因此，必须在其目录中具有该DLL。这意味着我有一堆API dll的副本似乎没必要。我宁愿只有一个地方可以放置我需要的程序集（比如应用程序根目录下的lib文件夹），主机和所有插件都可以找到它们。这可能吗？也许加载不同的addin（appdomain？）将允许他们查看主机app目录。我对MAF比较陌生，所以关于如何组织这个组织的任何建议都会有所帮助。
答案 0 :(得分：1)
你无法在.Net中执行的一件事是在加载后从AppDomain卸载DLL。如果不同的AddIns使用具有不同API签名的第三方DLL的不同版本，您可能想要这样做（比如说）。 MAF可以通过为每个AddIn实例化一个新的AppDomain来支持这一点 - 每个AppDomain都拥有它自己的第三方DLL版本。
这就是为什么你需要在每个AddIn文件夹中拥有第三方DLL的单独副本：允许您将每个AddIn与实现中的更改或其他AddIns中的依赖项隔离开来。
然而，答案还部分取决于.Net如何解决程序集依赖关系以及如何激活AddIns。
.Net将探测在其中使用类型的（不包括GAC）的AppDomain的BaseDirectory和PrivateBinPath中的程序集依赖性。
当您执行AddIn时，它在AppDomain中完成。如果您没有指定一个，您将为每个AddIn获得一个新的AppDomain，并且该AppDomain将BaseDir设置为AddIn文件夹 - 因此将在那里找到第三方DLL。
如果确实指定了AppDomain，那么将在该appdomain的BaseDir和PrivateBinPath中查找依赖程序集。这可以完全忽略AddIn文件夹中的任何第三方DLL！
请记住，MAF还有关于AddIn目录结构的时髦规则 - 它甚至禁止AddIn视图DLL位于AddIn目录本身。
为了支持AddIn的所有不同激活模式，我得出的结论是，AddIn文件夹中应该只有单个DLL 。我们正在更新我们的构建过程，以便将所有相关的DLL集成到AddIn dll中，包括附属程序集，Sgen序列化DLL以及第三方DLL。
考虑到这一点，也许您应该在构建过程中解决“重复DLL”问题？
答案 1 :(得分：0)
<runtime>
<assemblyBinding xmlns="urn:schemas=microsoft-com:asm.v1">
<probing privatePath="myfolder"/>
</assemblyBinding>
</runtime>