Why exactly isn't MEF a DI/IoC container?

Question

It's been said on the blogosphere and by Microsoft themselves that MEF isn't another IoC container.

OK...but why? It seems the same to me. Maybe it's not as good as Unity or Castle Windsor, but it still fits the definition, doesn't it?

Why isn't MEF an IoC Container like Unity or Castle Windsor?

Year

We covered this in a recent hanselminutes episode. hanselminutes.com/default.aspx?showID=166 – Fourwheeler

You could at least let me keep an upvote for the link to the herding code interview :) – Influx

Sure Kev. Sorry bout that, but the Glen blocks answer in hanselminutes was alot more detailed. The interview you posted was good, but left me with more questions than answers. – Year

Answer 1

MEF has potential, but as a DI container, it lacks:

1. Code as Configuration
2. Auto Registration
3. XML configuration (not so important to me)
4. Custom Lifetimes
5. Interception

Those things are pretty important.

For Lifestyle it lacks:

1. Per graph
2. Web Request Context
3. Thread Context
4. Session Context
5. Pooled
6. Scoped
7. Custom Reference

References: - Mark Seemann's book "Dependency Injection in .NET"

Disc

Answer 2

In my world DI is based on three dimensions, Object Composition, Lifetime Management, and Interception. This is what other full-blown DI containers, such as Unity, Castle Windsor, and Ninject facilitates. MEF only supports the one dimension, Object Composition. It is doing this quite well, but the remaining two dimensions are not supported in MEF.

Milly

Lifetime management is now significantly improved in MEF 2.0 in 4.5 / 4.0 on nuget in addition to having a convention based config model. Interception is not there, though MEF Contrib does have an extension for AOP / Interception. – Fourwheeler