Microsoft MEF Q&A with Hamilton Verissimo de Oliveira

I recently had an opportunity to bounce a few questions off the Managed Extensibility Framework (MEF) team at Microsoft. Hamilton Verissimo de Oliveira was kind enough to oblige me with my newbie questions.  So, if you have not heard of MEF or were fuzzy on what it can do for you, then read on.

Aslam Khan:  Tell us a little about yourself and the MEF Program at Microsoft.

Hamilton Verissimo:  My name is Hamilton Verissimo, I am deeply involved with Open Source for ..NET, have founded the Castle Project back in 2004, and joined Microsoft last year to work with the MEF team.

Aslam: Why do we need MEF?  Simply put, what are some of the pains that  MEF takes away from developers?

Hamilton:  Every application that wants to deal with extensibility face similar sorts of challenges. Our value proposition is to solve most of them in a very predictable way. Given that Visual Studio is one of our partners we were early introduced to a large chunk of challenges that come from big extensible applications. We aim to have solved if not all, most of them.

By being in the .NET framework, we also aim to have more pieces of the framework being extensible in a near future.

Aslam: Almost all new technologies introduces a new vocabulary.  For example, Aspects has pointcuts, joinpoints, etc.  which, IMHO, just  contributes to the confusion because it is poorly explained and  understood.  Now MEF introduces some new terminology like Parts, Catalogs, Exports and Imports, etc.  How about making an attempt to  peg down this vocabulary in a few simple sentences that just explains it all for us?  (Oooops, this sounds like a domain statement of sorts ;-)

Hamilton:  Indeed. We chose to do so as using a existing vocabulary would end up carrying semantics that we would rather be away from. For example, we prefer Parts to Components. Parts is fresh, hardly used by others frameworks. Components are overloaded with meaning, used by almost all frameworks.

Putting it as simple as possible:

• Parts: units of extension, implementors of contracts, targets of composition (also referred as ComposableParts)
• Catalogs: responsible for discovery, they go out there and find out what is a part of not (based on some encapsulated logic)
• Export: a facet/contract exposed by a part. It can expose more than one.
• Import: a dependency declared by a part

Aslam: Many people will look at MEF and say "it's just another dependency injection container" or "it's just another plug-in framework".  What makes MEF more compelling, i.e. is it perhaps greater than the sum of both these things?

Hamilton:  I can honestly say that MEF is an Inversion of Control Container, it's undeniable. The thing that is not clear is that it is a very specialized one. If you try to use it as you would normally use any other, you'll likely face limitations. That's because we aimed at the extensibility problem. We focused on open ended system where the set of parts that make your application is unknown to the implementor.

Checking on the surface it may look like that MEF is all about using some attributes on your classes, setting up a container and boom, things are composed. Going deeper, MEF works with an indirection layer we call Primitives. It virtually allows you to use anything to model data and behavior for "parts". We ship with just one model we call attributed programming model, but nothing prevents you from creating one based on Ruby, Python, configuration files, OSLO's models, XAML.

Finally, we had dedicated teams dealing with performance, debugging, security and endless questions like ownership and lifetime, friendliness/correctness of the public API.

Aslam: Clearly you are encouraging developers to embrace Interface-driven coding and applications are built by composition.  So there are two subtle mind-set changes here:  suddenly type is really important again and (de)composition analysis during design creeps in.  I consider these things as agile frictions: concrete type hierarchies and inflexible modules both carry taxes and can render you agile-less. How does MEF help us remain agile in this regard?

Hamilton:  I have to disagree. We encourage a more decoupled, isolated design, where parts declare what they expose to the outside (exports) and need from the outside (imports). That is plain Separation of Concerns and our goal is to ease and provide more opportunities for reuse. The side effects are also very agile, as it simplifies, for instance, unit testing.

Aslam: So the new WPF based editor in VS2010 is using MEF.  Tell  us a bit about how MEF is being used in this case.

Hamilton:  VS 2010 was rewritten - I'm not sure to what extent - to use WPF. The editor, and some other modules, are heavily relying on MEF. The code editor team designed a set of contracts that represent everything in the editor, like buffers, snippets. All of this has the goal to simplify the creation of extensions for VS.

Aslam: The MEF source code is available on CodePlex (http://www.codeplex.com/MEF).  What are some the significant community contributions that you have seen so far?  Will these contributions be merged into the main trunk or will they always be in a branch?

Hamilton:  Feedback is the main contribution. Making sure we're on the right path and we don't lose track of the real world problems is what we need to do to deliver something that adds great value to our customers.

Aslam: Thanks for taking the time to clear up the fog, Hamilton.