The Managed Extensibility Framework (MEF) More on Part Creation Policies -- Enter the ExportFactory

Last I blogged about part creation polices and why it might be a good idea to not say anything about them, and leave them as their default, "Any". This time I'm gonna talk about the ExportFactory which is what you'll wanna use for your object factory needs in the future.

Unfortunately, the ExportFactory didn't make it into the .NET 4.0 RTM build and that's a darn shame. However, MEF being open source and all, allows one to easily rectify the problem.

You can find all relevant source here. It contains a link to compiled binaries for several .NET Framework versions and source code that you can drop into any existing framework/core assembly you have. I've done this with the .NET 4.0 RC version of MEF without much of a problem. But you'll need to configure your CompositionContainer some more.

var catalog = ... // get a catalog here
var exportFactoryProvider = new Microsoft.ComponentModel.Composition.Hosting.ExportFactoryProvider();
container = new CompositionContainer(catalog, exportFactoryProvider);
exportFactoryProvider.SourceProvider = container; // a bit odd, but necessary

The ExportFactory is used in the same way as the Lazy<T,TMetadata> type and will create instances when you ask for them. This conveniently avoids the hassle of having to manually compose objects created through the common factory pattern. The instances served by the ExportFactory will already have it's imports satisfied, so no additional steps are required. MEF makes it fun!

e.g.

[ImportMany]
public ICollection<ExportFactory<IMyObject, IMyObjectMetadata>> Objects { get; private set; }

I ran into problems when using constructor injection, if you follow the link above you'll find out how I worked around that.

The Managed Extensibility Framework (MEF) Part Creation Policies

I'm gonna kick of a series on MEF partly for my own benefit, but maybe this will make sense to you as well. However, this won't be a beginners tutorial.

MEF ships with 3 types of part creation policies, Any, Shared and NonShared. By default all exports get the CreationPolicy.Any. What's a lesser known fact is that this allows the consumer -- imports -- to specify either CreationPolicy.Shared or CreationPolicy.NonShared.

Both attributes [Import] and [ImportMany] has a RequiredCreationPolicy property which let's you specify how the imports are satisfied. I tend to prefer to imply the correct behavior on the consumer side and not mandate that the producer has to think about it. With the default policy being CreationPolicy.Any a convenient factory pattern just imports with the CreationPolicy.NonShared. And if you're importing a collection you just don't have to worry about the composition failing, because if it's not working they're doing something wrong, it's not your problem.

Of course if you export a specific policy and import the other policy, the import is not satisfied which can lead to an unexpected exception being thrown.

Best of MIX2010

• DS13 The Elephant in the Room

  About 5 minutes in I felt I had to stop watching this, but it turned out to be the best presentation I've seen at the MIX 2010 conference. Thank you Nishant for an hour and a half of delightful material.

• DS16 An Hour With Bill Buxton
• DS07 The Art, Technology and Science of Reading

I would also recommend Joe Belfiore presentation CL01 Changing our Game – an Introduction to Windows Phone 7 Series and the others that continue the Windows Phone 7 Series. It's a really interesting piece of technology and beautifully designed with great potential.