我有一个基于MEF的应用程序,它使用适配器来处理文件。它使用配置文件来确定要监视的目录以及用于处理每种类型文件的适配器。插件采用.dll的形式,实现了一个通用接口。
每个.dll都需要自己的一组依赖库。例如,plugin1.dll可能需要使用apilibrary.dll和xmllibrary.dll。也有可能在以后我可能想添加plugin2.dll,而plugin2.dll也可能使用xmllibrary.dll。这些依赖库会定期更新,因此我不能指望使用plugin1.dll中使用的完全相同版本的xmllibrary.dll来插入plugin2.dll。
我想将每个插件编译成一个.dll文件,该文件隐藏在其自身的所有依赖库中,这似乎是解决此问题的一种方法。或者,我想弄清楚每个.dll文件如何在子文件夹中查找其依赖库,我相信这也会减少版本冲突的可能性。或许这个问题有一个简单的解决方案,我甚至都没有考虑过(这总是非常非常可能)。
有什么想法吗?
答案 0 :(得分:1)
我想你需要权衡可部署性和维护性。简单的解决方案是使用名为 ILMerge 的工具。 ILMerge接受您的项目输出,并可以采用其他程序集并将它们合并在一起。这使您可以包装插件所依赖的所有程序集,并将它们合并到一个程序集中。您可以选择使用公钥重新签名等。以下是Leveraging ILMerge to simplify deployment and your users experience的Daniel Cazzulino。
但是虽然这很好,如果分发了一个新版本的引用程序集来纠正你嵌入的错误,会发生什么?通过Fusions程序集加载器的规则,当它从引用的程序集中加载类型时,它将看到它们已经被加载,因此没有理由加载它们。这意味着您需要重新编译插件并再次合并较新引用的程序集。
我的问题是,真的对确保使用特定版本很重要吗?如果较新的版本提供了更新的实现(不会破坏向后兼容性),那么这肯定会使所有需要引用它的插件受益吗?
至于如何相互加载程序集,请阅读Understanding .Net Assemblies and References,这是一段非常宝贵的信息。
答案 1 :(得分:1)
您应该尝试使用标准.NET加载规则。但是,如果您确实需要精确控制程序集的加载方式以及加载的版本,则此博客文章将说明如何:Using Loading contexts effectively
答案 2 :(得分:0)
MEF使用标准.NET程序集加载,并且所有内容都加载到单个AppDomain中。您几乎无法控制依赖项的加载方式 - 因为它们只是在通过MEF注入程序集时由CLR自动加载。正常的CLR程序集加载规则在使用MEF时适用,因此依赖项将被加载,就像它们是应用程序的依赖项一样 - 无论它们位于何处或被引用。
在大多数情况下,如果正确编写了插件及其依赖项,您很可能不必担心这一点。只要依赖项中的版本控制是正确的,它就可能正常工作。