问题标签 [mef]

背景简介：

我的团队决定使用 Microsoft 的托管可扩展性框架 ( MEF ) 来提供可扩展模型，以便将新的“提供者”添加到我们的系统中。

这使我们能够相对轻松地插入新的第 3 方提供商。

注意：MEF 的使用、启动和运行的简单程度给我留下了深刻的印象。

我的问题：

由于这些提供程序通常具有与之关联的不同属性，因此在运行时将这些提供程序加载到系统中时，我们需要访问提供程序的数据流和属性。

由于属性不同，应该采取什么方法来使用所述提供程序插件？注意到他们都做类似的工作。

我的解决方案：

创建提供者必须遵守的接口，从而围绕每个第 3 方提供者创建一个“包装器”，从而为每个提供者提供一致的接口/编程模型。

插件 = 3rd 方数据源（提供者）+ 通用接口实现。

+ve：对于所述插件，不需要更复杂的基于反射的动态“插件”。

-ve：必须为每个提供者编写一个包装器。（无论如何，我们都需要添加 MEF 导出标签）

进一步说明：

对我来说，接口/包装器方法是最简单的，但有人告诉我研究一种基于反射的方法，该方法可以利用反射来发现运行时可以暴露给系统的属性。

我不赞成任何一种解决方案，但我很想听听社区的想法（其中大多数人比我更有经验）。

谢谢。

Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.

Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.

我有一个 asp.net 应用程序，它使用模型程序集（带有模型类）进行业务逻辑。该模型程序集通过 IMailService 接口依赖于 MailService，我正在尝试使用 MEF 来满足模型对 MailService 实现的需求。我正在 Model 类的构造函数中进行 MEF 组合。

这背后的想法是创建一个 MailService 程序集，我可以在我的网站之间重用，而网站本身不需要知道邮件是如何发送的。也许 IoC 容器会是更好的选择，但我只是认为 MEF 方法更易于理解，并且我喜欢通过组合部件来组成我的应用程序的想法。如果与 IoC 容器相比，mef 方法是否也有负面影响？

下面的代码在另一个程序集中，接口在另一个程序集中

这在我对模型程序集的单元测试中运行良好，但是当我通过我的 asp.net 站点使用模型程序集时，它会失败，但出现以下异常。我还尝试在 web.config 中将信任设置为完全，但仍然没有运气

组成保持不变。由于以下错误，更改被拒绝： 合成产生了单个合成错误。下面提供了根本原因。查看 CompositionException.Errors 属性以获取更多详细信息。

1) 找不到与约束匹配的导出 '((exportDefinition.ContractName = "ExtensionInterfaces.IMailService") && (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") && "ExtensionInterfaces.IMailService".Equals(exportDefinition.Metadata.get_Item( “ExportTypeIdentity”））））'。

导致：无法在零件 Model.Model' 上设置 import Model.Model._mailService (ContractName="ExtensionInterfaces.IMailService")'。元素：Model.Model._mailService (ContractName="ExtensionInterfaces.IMailService") --> Model.Model

MEF 在多大程度上（如果有的话）是 PRISM 的替代品？

我目前需要提供一种在我的应用程序中添加可扩展性的方法。我目前正在研究 MEF 和 MAF。

MEF 提供了一个更简单的编程模型，也更适合我们的使用场景，因为我们只想将插件加载到单个 AppDomain 中——这是由于系统的架构方式造成的。同样的事情也可以用 MAF 用几行代码来实现。

但是，鉴于 MEF 处于预览状态，我想知道是否应该在生产系统中使用 MEF？

我所有的“部分”都实现了这个 IPlugin 接口。我的零件显然有进口/出口要求/产品。

我正在编写一个构建+配置系统，用户可以在其中动态选择他/她想要的东西，这意味着一组插件被调用。

例如，这是一个插件列表：

(1) 安装 X ... 导出“XTypeInstalled”

(2) 配置X ...导入“XTypeInstalled”，导出“XTypeConfigured”

(3) 安装 Y ... 导入“XTypeConfigured”

(4) 安装 Z

(5)配置A

现在，用户可以选择 (1)、(3) 和 (4) ... 或者可以选择 (1)、(2)、(3)

我面临的问题是，我所有的插件编写者现在都需要实现 IPartImportsSatisfiedNotification 吗？如果不是，并且用户选择 (1)、(2) 和 (3) 的工作流程……我如何调用 (3) 的 execute() 方法。

我说得有道理吗？！

我的最终目标是将控件加载为插件，用作 AvalonDock 中的 DocumentContent。因此，我将需要能够创建这些控件的多个实例，并且我希望尽可能减少插件创建者的开销。

我最初的意图是使用 MEF 来定位和管理我的插件，但这个问题似乎暗示，至少在这个时间点，MEF 可能不适合这个。

我应该使用另一种解决方案（是 DI 容器的域，或者特别是 MEF，被认为仅限于提供类的实例，并且是否有另一种解决方案可以更好地映射到我的问题），或者我应该使用建议的解决方案（例如使用对克隆实例的反射，或要求插件创建者提供工厂方法/对象 - 看似 hackish）以使用/围绕 MEF（或者，是否有一种简单的方法来配置 MEF 来实现这一点）？

我正在为 WPF 应用程序使用托管可扩展性框架。我为所谓的扩展点定义了接口，这些接口为应用程序提供了新功能。

其中一些功能可能是使用某些数据模板显示数据，这是您可能希望在 xaml 资源文件中指定的内容。

如果我在应用程序编译时未知的程序集中定义了这些扩展点之一（即普通语言的插件），但我仍然想将插件的资源与应用程序的资源合并，我将如何去做？

所有示例显示如何使用 pack URI 表示法状态执行此操作，当您引用的程序集在编译时已知时，该状态是解决方案。当您在编译时不熟悉程序集时，如何实现相同的目标？

我是 MEF 的新手，正在尝试使用它来构建插件系统，但我卡在了第一步。

我正在关注Andrew Whitechapel 的文章。我已经下载了他的示例代码，它运行正常（如果您删除了其中一个“导出”程序集——它们在他的示例中是互斥的——并引用了 MEF 程序集）。

该示例说明了导入单个零件。我想导入多个部分（都基于相同的界面）。因此，我将示例代码更改如下：

我还为 IEnumerable 导入了 System.Collections.Generic。

关键的变化是第一个。据我了解，这将允许我从多个组件中导入零件。但是，我收到以下错误：

在这一点上，我什至还没有添加多个“插件”程序集。还是只有那个。

为了完整起见，这是他在“插件”类库中的导出定义（我没有触及）：

有任何想法吗？我在这里挠头。我搜索了 SO 和 MEF 论坛，但可以找到任何可以启发我的东西。

我正在使用 VS 2008 SP1（未安装 2010 beta）和最新的 System.ComponentModel.Composition 程序集（2009.26.8.0）。

为标题道歉，我被卡住了

我在 MEF 池塘里踮起脚尖。到现在为止还挺好。我有一个主机应用程序和几个导出东西的“插件”程序集。宿主应用程序定义了一个名为的属性，该属性DescriptionAttribute继承自ExportAttribute并具有一个简单的Name属性。我的测试表格有一个<ImportMany> IEnumerable(Of Lazy(Of IDoStuff, IDescriptionAttribute)). 这被 MEF 很好地填满了，我可以在收藏中旋转，Name财产被填满，生活是金色的。稍后我会将内容拆分为单独的程序集，目前这只是一个概念证明。

现在，问题是：有什么方法可以公开实现的程序集版本，IDoStuff通过我拥有的属性DescriptionAttribute佩戴“插件”类？DescriptionAttribute到目前为止，我将其传递给属性构造函数的所有尝试都失败了，工作室一直告诉我需要一个常量表达式（可以理解）。我可以通过 IDoStuff 接口公开它，但是将它作为DescriptionAttribute属性的一部分会更好，“感觉”更好。我也可以对其进行硬编码，但这是我在发布“插件”的新版本时忘记更新的另一个地方:-)