（我知道其他MEF / MAF问题，但这是一个更具体的问题）
我想创建一个WPF应用程序，它基本上只是一个简单的外接程序主机，GUI和设置。所有实际工作都将由一个或多个插件完成。它们不需要彼此通信，主应用程序将向用户发送用户输入/命令，并且它们将返回一些结果（例如，要呈现的WPF UI元素）。
现在，由于应用程序的核心将基于插件，我需要选择一种管理它们的好方法。我希望能够在运行时加载/卸载/重新加载它们（例如，当找到并下载更新时）。它们应该在自己的应用程序域和/或进程中运行以确保稳定性和安全性。
通过一些研究和实验，我得出了三个选择：
System.Addin（MAF）：看来这可以做我需要的一切。有一个管道允许同时运行多个版本的API以实现兼容性等。但除非我遗漏了一些东西，否则我需要多次创建API - 主机和插件视图，合同和两个适用于合同的适配器。此外，与MEF相比，信息和资源也很少，大多数文章都是几年之久。我担心这种情况会慢慢消失，宁愿不再用于新项目。
MEF：这个看起来更简单，但感觉还有很多我无法控制的魔法，并且这些层没有像MAF那样分开。我只想要一个小型库，你可以链接到一个新项目，实现界面，插件就完成了。
手动加载：最后一个选项是手动扫描 .dlls 的文件夹，使用反射来查找插件类和创建实例。虽然它是可行的，但我宁愿使用一些框架而不是手动加载程序集，创建单独的进程/ appdomain等。
那么，哪一种最适合这种应用，还是有一些我错过的东西？
答案 0 :(得分：10)
MEF绝对是三者中最简单的选择。它的设计考虑了这个确切的场景（可扩展的应用程序）。
它实际上是Visual Studio使用的“插件”机制，它是一个WPF应用程序。您需要做的就是让您的“插件”实现一个接口或从已知的基类派生，并添加[Export]属性。如果它的程序集已添加到主应用程序的目录中，则该类型可由主应用程序[Import]一步完成。这项工作涉及的工作很少。
这是我的建议，除非有充分的理由选择不同的选择。 MAF具有更多的隔离支持，但使用起来要困难得多，并且大多数隔离功能在WPF应用程序中都无法使用，因为WPF中的UI在任何情况下都不能真正成为隔离代码。