Disclaimer: This is not an encouragement to use MEF to replace your IoC container, these are guidelines to help those who are considering it's use.

This has been a question we hear again and again both internally and externally.  MEF in V1 is targetting third-party extensibility scenarios, or open-systems which discover their components rather than having them explicitly configured. This is why our attributed model was crafted in the fashion that it was.  Now that doesn’t answer the question, “Can I use MEF today for my general IoC needs?”. Like all things in software, it depends ;-), in this case on what your IoC needs are.

Update: The list has been updated based on feedback from my team.

On first glance, MEF may seem to be very similar to your favorite IoC container. However as they say, the devil is in the details. Here are a few details to consider which should help you in your decision and set proper expectations about using MEF:

• If you  need/want centralized configuration of plain old CLR objects (POCOs) then MEF is not the right choice.
  • We do have TypeCatalogs which allow you pick and choose which Types you have in the container, but those types still have to attributed, thus the configuration mechanism is configuring which attributed MEF parts show up. This is because our attributed model is really optimized around discovery of a set of unknown components vs configuring a pre-defined set.
  • As we don't have a central configuration mechanism, we also have no explict way to pipe configuration settings like "Port" or "Uri" into a specific part.
• If you need AOP/Interception like injecting logging, or automatic transcation management then MEF doesn’t include any native support for this.
• Open generics support (register IRepository<> which can handle all IRepository<T> dependencies) is not baked in.
• If you need custom lifetime support such as per-thread, per-session MEF includes only two lifetime models, shared and non-shared. To get more complex lifetimes requires manually setting up container hierarchies. It is doable, but requires work.
• If you need paramterized construction, that is creating a part where specific imports are passed in at the time of construction, then this is also not supported.

In enterprise applications with a large number of different types of components, the above list will probably be more significant. However, if none of the above are core concerns then MEF might be fine for your needs.    MEF does an excellent job of decoupling implementations and assembling component hierarchies, but it is tailored today for implicit composition and discovery.

In the next version of MEF that will ship post .NET 4.0,  we are planning to focus more on explicit composition, and will be addressing many of the items on the above list. Until then, it is likely that there will be some great community implementations such as MEF Contrib which will address many of these concerns, but these are not part of MEF itself.