MEF and DI/IOC

MEF and IOC are two different design patterns created for two completely different scenarios.

1. IOC is most useful with Static dependencies , MEF is useful for dynamic dependencies.
2. IOC is for registration of known parts whereas MEF is for discovery of unknown parts.
3. When working with/for 3rd party dlls , MEF is more the best choice.
4. Id you have two dlls, taking a decision at runtime to swap the two is possible using MEF and not IOC.
5. The principle purpose of MEF is extensibility; to serve as a 'plug-in' framework for when the author of the application and the author of the plug-in (extension) are different and have no particular knowledge of each other beyond a published interface (contract) library.
6. Plug-in versioning problem is not there in MEF , but may present in IOC.
7. Again, MEF 'intent' is tightly focused on anonymous plug-in extensibility, something that very much differentiates it from other IoC containers. So while MEF can be used for composition, that's merely a small intersection of its capabilities relative to other IoCs, with which I suspect we'll be seeing a lot of incestuous interplay going forward.
8.  MEF is basically using some IoC-like principles to enable application composition and dependency management.  So in some way it's kind of like IoC for your application.  It's focused on discovering components and letting your application compose itself on the fly.  It's designed for larger applications like Visual Studio.  Now that I understand it, and, yeah, it's pretty darn cool.
9. In my opinion, IoC is more about a consistent loose-coupling pattern across your app, and in many ways the factories act like smart service providers, with the containers adding a variety of ways to configure how query resolutions are done at a particular point in time (e.g. they allow you to register bindings in config or in code, statically or dynamically, etc.)