Wes' Puzzling Blog : MEF

MEF preview 5 released

puzzlehacker — Wed, 08 Apr 2009 02:20:17 GMT

My team released the 5th source code preview of MEF (Managed Extensibility Framework). You can get the latest bits at MEF preview 5. A summary of the changes can be found on in the release notes but I will copy them here for convenience. If you have questions or concerns feel free to join the discussion.

Namespace changes

System.ComponentModel.Composition – For part authors. This namespace contains the import and export attributes as well as other APIs that part authors are likely to use.
System.ComponentModel.Composition.Hosting – For hosters. This namespace contains the CompositionContainer, catalog implementations, and other APIs that hosters are likely to use.

Part discovery changes

CompositionOptionsAttribute and DiscoveryMode have been removed.
PartNotDiscoverableAttribute replaces [CompositionOptions(DiscoveryMode = DiscoveryMode.Never)]
PartCreationPolicyAttribute can be used to specify part creation policy (Replaces CompositionOptionsAttribute.CreationPolicy)
By default, exports on a base class will not be included in the exports for a derived class.
The PartExportsInheritedAttribute can be applied to a base class to specify that exports on that class will be included in derived classes. NOTE: If this attribute is used, and both the base and derived class have export attributes applied to them, there will be multiple exports created for the same class. Also note that whatever metadata is applied to the export on the base class can’t be added to or overridden by the derived class

Collection imports

ImportManyAttribute should now be used on collection imports (in the future, an ImportAttribute will not be interpreted as a collection import even if it is applied to a collection type).
Array imports are now supported.

Typed Imports/Exports

Imports and Exports now match on type as well as contract.
Exporters of string contracts such as [Export(“Foo”)] must now specify the type they expect to be imported as well. e.g. [Export(“Foo”, typeof(string))]

Method exports

Method exports can now be imported as custom delegates in addition to Action<…> and Func<…> delegates

Directory Catalog

The directory watching functionality has been removed. The Refresh() method has been added to explicitly update the catalog with new assemblies in the directory.

Removal of Caching / new infrastructure

The old caching infrastructure has been removed. We’ve added a general purpose API that allows the implementation of catalog caching as well as supporting builders of custom programming models. The APIs are members of the static class System.ComponentModel.Composition.ReflectionModel.ReflectionModelServices. In the future we plan to ship a sample that shows how these APIs can be used to create cached catalogs.

New sample application

MEF Studio – a designer hosting sample.

Common compilation errors to expect when migrating previous code bases

System.ComponentModel.Composition.Container does not exist -> Add reference to System.ComponentModel.Composition.Hosting namespace
CompositionContainer does not contain method AddPart or Compose -> Need to start using CompositionBatch, or one of the helper extension methods ComposeParts or ComposeExportedObjects
CompositionOptionsAttribute does not exist -> For CreationPolicy use PartCreationPolicyAttribute
INotifyImportCompleted does not exist -> Use IPartImportsSatisfiedNotification interface and change method from ImportCompleted to OnImportsSatisfied

Should MEF support non-shared components?

puzzlehacker — Mon, 10 Nov 2008 19:16:00 GMT

Hamilton has posted about the question of whether or not MEF should support non-shared as well as shared components (non-shared==factory and shared==singleton in our current public bits). In an ideal world we would love to support both but currently every solution we've come up with to support non-shared components has issues. We could pick a solution that we feel properly balances the advantages and disadvantages but that would require us to foresee exactly how the world is going to use MEF. While we believe we could pick a reasonable balance there is fear that we would pick the wrong balance for the majority of our future users. Therefore one approach to combat this is to not support non-shared components, at least in V1, and see what usage patterns reveal themselves in the wild and target that balance in V2.

Do you feel that it would be a mistake for the MEF team to only support shared/singleton components in V1? Keep in mind that there are patterns, as Hamilton pointed out, to still support non-shared/factory if you needed that support in V1.

MEF CTP2 released with source code.

puzzlehacker — Wed, 10 Sep 2008 05:28:21 GMT

My team released MEF CTP2 on codeplex at http://www.codeplex.com/MEF, this time with source code. We also created a number of documents (i.e. wiki pages) and samples that demonstrate how to use MEF.

What problems does MEF solve?
MEF presents a simple solution for the runtime extensibility problem. Until now, any application that wanted to support a plugin model needed to create its own infrastructure from scratch. Those plugins would often be application-specific and could not be reused across multiple implementations.

MEF provides a standard way for the host application to expose itself and consume external extensions. Extensions, by their nature, can be reused amongst different applications. However, an extension could still be implemented in a way that is application-specific. Extensions themselves can depend on one another and MEF will make sure they are wired together in the correct order (another thing you won't have to worry about).

MEF offers a set of discovery approaches for your application to locate and load available extensions.

MEF allows tagging extensions with additional metadata which facilitates rich querying and filtering

[MEF Overview]

By all means please provide us with what you like and\or dislike about MEF at Discussions.

First Managed Extensibility Framework (MEF) bits released

puzzlehacker — Thu, 05 Jun 2008 05:07:39 GMT

Today was a big day for my team because we released the bits for the first CTP of the Managed Extensibility Framework (MEF).

MEF is a framework that allows developers to declare what they need (i.e. Imports) and what they provide (i.e. Exports) and then automatically wire up everything at run-time. While that may be a slight over simplification it is the basic idea and can lead to a very loosely coupled system which can easily be extended and evolve overtime.

The primary goal of this CTP is to get the bits into people’s hands early to gather feedback from the community and feed it back into the product. We have already gotten some good feedback in response to Krzysztof’s blog post about MEF, and some of that feedback has already made its way into the CTP. Rest assured that there are still community asks that we are still actively working hard on.

Keep in mind these bits are very early and you should not get hung up on the names and exact shape of the API’s because they are likely to change. What we would really like is feedback on the basic concepts and any scenarios you feel MEF would be useful for but needs some fine tuning.

To get your hands dirty download the bits and have a look at the sample applications and docs. If you have questions or feedback by all means don’t hesitate to stop by our forum.

Expect so see some more posts from me and some of my teammates (Mitch, David, Krzysztof) on MEF in the coming months.

Enjoy!