In honor of MEF reaching its feature complete milestone, we take a look at the confused story of extensibility in the .NET Framework. MEF or Managed Extensibility Framework is the fourth extensibility framework to be released by Microsoft. Though like all the previous times, Microsoft is claiming that it is the first.

MEF presents a simple solution for the runtime extensibility problem. Until now, any application that wanted to support a plugin model needed to create its own infrastructure from scratch. Those plugins would often be application-specific and could not be reused across multiple implementations.

But that is not true. In addition to the third-party frameworks like Spring.NET, there are at least three other extensibility frameworks for the .NET runtime just among developed by Microsoft itself.

System.Addin is a great technology for addressing issues around versioning resliance, isolation and recoverability.

Using System.Addin allows you to host different components in separate app domains, thus allowing those addins to have different versions of assemblies which they reference which all run in the same process.

System.Addin allows you to separately version Addins so that you could have two versions of an Addin sitting side by side.

System.Addin manages automatically unloading app-domains they are no longer used thus allowing you reclaim memory.

System.Addin has a bunch of security infrastructure (addins run in a sandbox) to ensure that components that are loaded do not have unauthorized access to data in the rest of the app.

System.AddIn allows your app to gracefully recover whenever one of the addins crashes (this is due to isolation)

MEF on the other hand is a great technology for discovery and composition

MEF composes deep object hierarchies of components

MEF abstracts components from static dependencies.

MEF can allow components to be lazily loaded and lazily instantiated.

MEF provides a cataloging mechanism and rich metadata for components to allow them to dynamically discovered.

MEF can compose components from various programming models, it is not bound to static types.

Rather than simply build MEF on top of the Add-In Model, which they admit has some significant advantages in terms of isolation for security and stability, MEF seems to have been built from scratch with little or no consideration for the preexisting technology.

The confusion over the two technologies suggests that there are some disputes within Microsoft. On one side we are seeing videos with titles such as Creating Extensible Applications with the Managed Extensibility Framework. In November the Program Manager Gleen Block was even claiming that, “MEF is being position as the framework for extensibility going forward”.

One possible explanation for this is that the Add-In Model just doesn’t work for most people. It is an embarrassingly complex framework and code generation tools such as the System.Addin Pipeline Builder are needed just to get started. And it should be noted that this is the second incarnation of that project. It was forked from the original because it wasn’t being maintained and bugs were not being fixed.

So what will be the final fate of System.AddIn? With no one willing to say otherwise, it seems like it will be quietly abandoned just like LINQ to SQL.

- IoC and addins are two very different things. I don't see a conflict between Unity and MEF.

- The Composite Application Library is even further from the other two.

Maybe they could/share some code, but that's beside the point.

There really are some unanswered questions about the future of System.AddIn and its relationship to MEF. I think that's bad enough, no need to exaggerate the story.

BTW, has LINQ to SQL really really been "abandoned"? The official version was that they just didn't want to extend LINQ to SQL until it matches EF, ending up with two libraries adressing the same problem (very much what you're criticizing here). They'd rather have a lean-and-mean LINQ provider with very basic ORM capabilities (LINQ to SQL) and a full ORM for enterprise apps (EF). This makes a lot of sense to me.

I think that your statement that "[MEF] is the official dependency injection framework for the .NET Framework." is incorrect. It is an extensibility framework, not a DI/IOC framework. While internally it may use a "container" to fulfill that role, that is a mere implementation detail.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.