As the name implies, Managed Extensibility Framework is a framework for extending .NET applications. In a recent Channel 9 interview Oleg Lvovitch and Kevin Ransom talked about the history of MEF and what’s planed for version 2.
MEF has the unfortunate distinction of being the most misused library in .NET. One can often see developers trying to use it as a general purpose Dependency Injection framework or an Inversion of Control Container, roles that it is ill suited for. Some even go so far as to use it in lieu of using the “new” operator. Glenn Block of Microsoft explains what the Managed Extensibility Framework is really meant for:
We are not aiming for MEF to be an all-purpose IoC. The best way to think about the IoC aspects of MEF is an implementation detail. We use IoC as a pattern because it is a great way to address the problems we are looking to solve.
MEF is focused on extensibility. When you think of MEF look at it as an investment in taking our platform forward. Our future products and the platform will leverage MEF as a standard mechanism for adding extensibility. Third-party products and frameworks will also be able to leverage this same mechanism. The average "user" of MEF will author components that MEF will consume and will not be directly consuming MEF within their applications.
Imagine when you want to extend our platform in the future, you drop a dll in the bin folder and you are done. The MEF enabled app lights up with the new extension. That's the vision for MEF.
By far the most important application in the history of MEF is Visual Studio 10. Many features such as the delay loading of everything and finely grained contracts were in answer to the needs of the editor in Visual Studio. The use of MEF in Visual Studio will increase significantly in Visual Studio 11 as managed code slowly replaces the COM-based extensibility model.
MEF 2.0 is intended to be a reactionary version. Most of the features are intended to address feedback from both the Visual Studio teams and the community at large. One important change is the simplification of the programming model. While suitable for complex applications such as Visual Studio, the hosting APIs are overkill for small applications with only a handful of extension points. This is still a work in progress and no details were provided.
On the other side of the spectrum, MEF is looking to include better support hierarchies of containers. Each container would add its own context to the context it inherited from its parent. For example, the Visual Studio shell might be one container. Within it are containers for each project, with the context holding information such as the type of project and what files it contains. A third container may be an editor for a single file. MEF 1 can already handle this, but in a clumsy fashion.
A major problem in MEF 1 is the inability to diagnosis composition problems. Without the source code for MEF and a well-placed break point, determining the exact cause could be quite difficult. A lot of effort has been put into MEF 2 to ensure that this will no longer be an issue.
A new feature in .NET 4.5 is customized reflection contexts. One can use a reflection context to add declarative attributes to a class at runtime based on rules expressed in normal C# code. The RegistrationBuilder in MEF 2 will honor these custom attributes and act as if they were there all along. This allows the use of POCO types in MEF even when one doesn’t have access to the source code of the type.
MEF will also be available for Windows 8 Metro applications, but in a very different form. Most of the advanced functionality has been removed and what’s left is focused on MEF’s primary purpose, the exposure of extensibility points and loading of extensions.
