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

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

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

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

当你在 C# 中使用 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，而不会抛出明确的错误信息。这正是使用 MEF 进行插件式开发时需要高度警惕的地方。