What is missing in MEF to be on par with IoC containers?

Question

MEF is not an IoC container. But it seems that it is almost an IoC container. It seems that I can easily make MEF behave like an IoC container (see example below) and there is not much missing to make MEF a full blown IoC container.

What are the actual features that are missing in MEF that StrucureMap, Unity, etc. have to get on par?

Would you think, this feaure request makes sense?

using System;  
using System.Collections.Generic;  
using System.ComponentModel.Composition;  
using System.ComponentModel.Composition.Hosting;  
using System.ComponentModel.Composition.Primitives;  
using System.Linq;  
...
private CompositionContainer container;
public void Configure()  
{  
    container = CompositionHost.Initialize(  
        new AggregateCatalog(
            AssemblySource.Instance.Select(
              x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));       
        var batch = new CompositionBatch();        
        batch.AddExportedValue<IWindowManager>(new WindowManager());  
        batch.AddExportedValue<IEventAggregator>(new EventAggregator());  
        batch.AddExportedValue(container);        
        container.Compose(batch);  
 }  

Answer 1

What is missing in MEF to be on par with IoC containers?

A way to easily diagnose problems in a composition.

For example, if you have a dependency chain A -> B -> C -> D, and D is missing, then according to the principle of stable composition MEF will simply mark A, B and C as unavailable and will try to do the composition without those parts. Your error message is going to complain about A, not D.

To diagnose the problem, you'll have to dump the composition diagnostics somehow (e.g. with mefx) and painstakingly follow the dependency path downwards until you find the actual problem. Which is a pain but sort of works, until you introduce cyclic dependencies...

A regular IoC container does not have this problem. It will simply tell you "hey, you've registered C for use in the composition but I can't seem to find its dependency D".

See also my blog post on this topic.

Answer 2

As discussed, MEF wasn't built to be an IoC container. However, it has a lot of similarities. If the functionality MEF provides is enough for your IoC container needs, then you can go ahead and use it as an IoC container.

While MEF will probably never suit everyone's IoC container needs, in the next version we are making changes that I think will make it worth using as an IoC container for more people. Here are some of them:

• Optionally disabling rejection for easier diagnosis of errors in a system where you don't want anything to be rejected
• Convention model support that lets you register types to be exported and imported instead of adding export and import attributes on the types themselves.
• Open generic support, so you can export an open generic and import a closed version.
• Better support for scoped/heirarchical containers, which may help with lifetime management.

Thomas mentions interception as an important feature. We don't currently have plans to include support for this out of the box. MefContrib does have some support for this in the form of an InterceptingCatalog, I believe.

Answer 3

I'm not aware of the lates features of MEF but what can I say is that MEF is a framework that addresses extensibility concerns for applications. The focus is on enabling add-in scenarios for standard software. It shares so many traits with ‘proper’ IoC Containers that it may become a full-fledged IoC Container in the future.

Mef was built for a different purpose then a IoC container. Its purpose is to provide a common framework for enabling add-in functionality for standard applications. From the perspective of a standard application, an add-in is essentially an unknown component.

When we use a IoC Container as a tool to compose an application, we know about the components that make up the application.

IoC containers aims decoupled composition of services which is good but the developper should know about the components he wishes to compose at the time the conainer is configured when MEF aims the discoverability of components. The only thing you should know is about a abstraction you want to use.

MEF shares so many similarities with IoC Containers that sometimes it's hard to say how we should consider it.

I think that the main disaventage of MEF is :

• poor lifetime managment compared to IoC
• lack of interception

Which are the main points when talking about IoC containers.