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.

New unit for speed, courtesy of Microsoft Windows

Difficult != time consuming

There. I said it. Difficult problems are problems that lack a solution. Problems that can be solved, problems that have many existing solutions today, are not difficult. Not all problems are difficult, but they are time consuming and it would be preferable if they could be solved by someone else. The problem with such a solution is that things change, and when you rely entirely on other people for your solutions, you'll lose the ability to adapt in a situation when your out of the box (component) or solution can't sustain your domain. That's why you sometimes have to do things yourself, in your own way. Because no one else understands your problems that well.

Publishers want a law to control online news access

I just recently stumbled upon this comment while reading this article over at Ars technica.

Maybe I'd feel a little more sympathy for the press if they actually did their jobs nowadays. Rewriting press releases in your own words is not journalism. Reporting on what is on Twitter is not journalism. Running yet another story on the most popular video on Youtube is not journalism. It's mimicry. Very little actual journalism happens anymore. The rare exception is local news, where you do get reporters going to committee meetings, calling multiple sources, and in general doing research. But national news? Eh. They do little more than rewrite press releases.

Evolve or die.

I couldn't agree more, I don't watch TV and generally avoid newspapers because of the sub-par writing. I tend to prefer my first-hand sources, here on the Internet.

What bothers me is that it seems like someone, or something is trying to control the flow of information... this is why we built the Internet and it's not about control, it's all about sharing!

MIX09

• Doug Purdy and Chris Sells talks about developing RESTful Services and Clients with "M"
• Seema Ramchandani also gives two decent talks about Silverlight graphics and preformance, I reccomend both for anyone intrested in Siliverlight or WPF.
• The return of Johnny Lee with more Wii and HCI stuff.

Go to the http://videos.visitmix.com/MIX09/ website and check out the rest of this year's presentations.