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:
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.