c#如何使用MEF框架_c#MEF框架的正确用法与注意事项

CompositionContainer 初始化失败常因类型反射加载失败，主因是程序集版本/框架不匹配、DLL未显式加载或缺失部署依赖；Import为null则多因Catalog未包含对应Export、路径错误或契约不一致。

为什么 CompositionContainer 初始化失败常报“Unable to load one or more of the requested types”

遇到这个错误，先别急着怀疑 MEF 框架本身。问题的根源，十有八九出在类型解析的反射加载环节。简单来说，就是容器在运行时找不到你定义的类型了。这通常由几个典型场景导致：引用的程序集版本对不上号、目标框架不一致（比如插件是用 .NET 5 编译的，而宿主程序跑在 .NET 6 上），或者，类型所在的 DLL 根本没有被加载到当前应用程序域中。

• 确保程序集显式可用：所有参与组合的部件，其所在的程序集都必须通过 Assembly.LoadFrom 等方式显式加载，或者确保它们已经存在于 AppDomain.CurrentDomain.GetAssemblies() 的列表里。
• 警惕未部署的依赖：如果你的 [Export] 类型里，引用了某些只在开发环境存在的 NuGet 包（例如一些调试分析工具包），而这些包没有随主程序一起部署，那么运行时自然找不到。
• 善用异常诊断：一个非常实用的技巧是，用 try/catch 捕获 ReflectionTypeLoadException。然后检查其 LoaderExceptions 属性，它能清晰地告诉你具体是哪个类型加载失败了，堪称定位问题的“火眼金睛”。

Import 属性为 null？检查 ComposablePartCatalog 是否包含对应 Export

这里有个常见的误解：MEF 会自动扫描整个应用程序的所有角落来寻找导出部件。事实并非如此。MEF 只会从你显式提供的 ComposablePartCatalog（目录）中去查找。如果你使用了 DirectoryCatalog，但插件 DLL 放错了路径、文件扩展名不对、甚至被安全软件锁定了，那么 Import 属性拿到 null 也就不足为奇了。

• 确认目录内容：直接检查 catalog.Parts.Count()。如果结果是 0，那基本可以断定是路径错误或程序集加载失败了。
• 注意文件类型：DirectoryCatalog 默认只识别 .dll 文件，对于 .exe 或无扩展名的文件，它是“视而不见”的。
• 别忘了主程序集：如果导出类就定义在主执行程序集里，务必记得用 new AssemblyCatalog(Assembly.GetExecutingAssembly()) 把它也加入到目录中。
• 契约必须严格匹配：导入属性上必须有 [Import]，并且其类型签名必须与 [Export] 的定义完全一致，包括命名空间。当使用接口导出时，如果指定了契约名称（contract name），那么导入时也必须使用相同的契约名称才能成功匹配。

用 ExportFactory 替代直接 Import 实现延迟创建与生命周期控制

直接使用 [Import] 有一个局限：对象会在组合容器构建完成时就被立即实例化。这导致你无法控制创建的时机，也难以管理其生命周期和资源释放。而 ExportFactory 正是为解决这个问题而生的。它提供了一个 CreateExport() 方法，允许你在需要时才创建实例，并且每个调用都会产生一个新的实例，同时支持通过 Dispose() 来显式释放。

• 导出端配置：在导出类上，通常需要这样标注：[Export(typeof(IMyService))][PartCreationPolicy(CreationPolicy.NonShared)]。
• 导入端声明：不再直接导入服务，而是导入它的工厂：[Import] public ExportFactory ServiceFactory { get; set; }。
• 使用模式：实际使用时，遵循一个标准模式：using var export = ServiceFactory.CreateExport(); var service = export.Value;。
• 关键提醒：如果导出类实现了 IDisposable，并且创建策略是 NonShared（非共享），那么务必在不再需要时手动调用 export.Dispose()，否则会造成实例泄漏。

.NET Core/.NET 5+ 中为什么 System.ComponentModel.Composition 不推荐继续用

对于现代 .NET 项目，需要明确一点：原生的 MEF（即 System.ComponentModel.Composition 命名空间下的 API）在 .NET Core 及更高版本中，更多是作为一个兼容层存在，功能上存在诸多限制。例如，它不支持 DirectoryCatalog 的热重载、处理跨平台路径时可能行为不一致、反射机制也与传统的 .NET Framework 版本有所差异。更重要的是，微软已将其标记为“legacy”（遗留技术）。因此，新项目应当考虑迁移。

• 主流替代方案：首选是转向 Microsoft.Extensions.DependencyInjection 结合自定义的插件加载逻辑。
• 社区 MEF2：另一个选择是使用社区维护的 System.Composition（常被称为 MEF2）。它是一个轻量级替代品，API 设计相似但并不兼容旧版 MEF，需要替换命名空间，并使用 ContainerConfiguration 来构建容器。
• MEF2 的优势：它提供了更精细的控制，例如通过 AssemblyPartDiscovery 可以更精确地筛选类型，避免意外加载测试类或内部工具类。
• 注意差异：MEF2 没有内置的 Lazy 自动包装机制。如果需要延迟加载，得手动用 Lazy 包裹 ExportFactory 来实现。

说到底，MEF 的许多“坑”都源于对“自动化”的过度信任。它看似帮你完成了所有依赖连线，但实际上，每一根线是否连通、接口是否严丝合缝，都需要开发者自己来仔细确认。尤其是在跨程序集的复杂场景下，类型加载、生命周期管理和契约匹配这三个环节，任何一个出了差错，都可能导致 Import 属性静默地变为 null，而不会抛出任何明确的错误信息。这才是最需要警惕的地方。