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);  
 }

score 4 · Answer 1 · answered Jun 17 '11 at 12:08

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.

You'll probably be happy to hear that in MEF vNext, there is a way to disable rejection so that it will throw an exception any time a part would be rejected. This should make it much easier to find the problem in systems where you don't expect anything to be rejected. — Daniel Plaisted, Jun 17 '11 at 15:54
@Daniel: Thanks, I had taken a look at the MEF 2 Preview 3 release but somehow I missed that. — Wim Coenen, Jun 24 '11 at 16:03

score 3 · Answer 2 · answered Jun 17 '11 at 10:29

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.

score 3 · Accepted Answer · edited Nov 21 '17 at 21:17

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.

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

3 Answers3