MEF (Managed Extensibility Framework) in .NET 4.0

What is MEF (Managed Extensibility Framework). MEF (Managed Extensibility Framework) in .NET 4.0For example you have an accounting application and you would like to provide a hook (socket) where external vendors can connect (plug) and add invoicing capabilities to the accounting application. For instance you have application which you would want different vendors to connect with their features and extend your application. So the vendors just put the components in the application, the application discovers them and does the connection and extension. The Managed Extensibility Framework (MEF) is a new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.

MEF offers discovery and composition capabilities that you can leverage to load application extensions. Here is my application, here is my hooks import (connect and extended like plug) and export attribute (explore and attach the plug) new features with my hooks and extension. Extend the application that you need. Use import attribute to define a hook, use export to implement new feature and plug. MEF is a framework by which you can make your application extensible. Application requirements change frequently and software is constantly evolving. As a result, such applications often become monolithic making it difficult to add new functionality. The Managed Extensibility Framework (MEF) is a new library in .NET Framework 4 addresses this problem by simplifying the design of extensible applications and components.  MEF is focused on application extensibility. It uses DI as a strategy for composing the different extensions, however it is not in itself a generic DI container. Composite Application Guidance for WPF is a set of guidance for building Composite Applications in WPF. While it does have a module loading facility for extensibility, the type of extensibility it offers is very specific for composite applications.

MEF (Managed Extensibility Framework) in .NET 4.0

What problems does MEF solve?

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.

MEF (Managed Extensibility Framework) in .NET 4.0

  • MEF provides a standard way for the host application to expose itself and consume external extensions. Extensions, by their nature, can be reused amongst different applications. However, an extension could still be implemented in a way that is application-specific. Extensions themselves can depend on one another and MEF will make sure they are wired together in the correct order (another thing you won't have to worry about).
  • MEF offers a set of discovery approaches for your application to locate and load available extensions.
  • MEF allows tagging extensions with additional metadata which facilitates rich querying and filtering

How does MEF work?

Roughly speaking, MEF's core is comprised of a catalog and a CompositionContainer. A catalog is responsible for discovering extensions and the container coordinates creation and satisfies dependencies.

  • MEF's first-class citizen is a ComposablePart (see Parts). A composable part offers up one or more Exports, and may also depend on one or more externally provided services or Imports. A composable part also manages an instance, which can be an object instance of a given type (it is in the default MEF implementation). MEF, however, is extensible and additional  ComposablePart implementations can be provided as long as they adhere to the Import/Export contracts.
  • Exports and imports each have a Contract. Contracts are the bridge between exports and imports. An export contract can consist of further metadata that can be used to filter on its discovery. For example, it might indicate a specific capability that the export offers.
  • MEF's container interacts with Catalogs to have access to composable parts. The container itself resolves a part's dependencies and exposes Exports to the outside world. You're free to add composable part instances directly to the container if you wish.
  • A ComposablePart returned by a catalog will likely be an extension to your application. It might have Imports (dependencies) on components the host application offers, and it's likely to Export others.
  • The default MEF composable part implementation uses attribute-based metadata to declare exports and imports. This allows MEF to determine which parts, imports, and exports are available completely through discovery.

 


(Managed Extensibility Framework) in .NET 4.0

This is the part that seems to confuse people when they ask, "Do we need another Unity?" MEF is far more than a substitute for dependency injection or inversion of control. However, it does manage DI and IoC quite well. With Unity, for example, I had to wire in a bootstrapper and configure the container, then either grab objects from the container to take advantage of constructor injection or explicitly request objects.

Get Microsoft Silverlight

In MEF, the parts model makes it far easier in my opinion. I simply make IFoo available:

Find this far easier to set up and manage consistently across large applications than worrying about when/where/how the container has been configured, whether or not I'm using a nested container, and then how to grab the desired implementation.


[Export(typeof(IFoo))]
public class Foo {}


public class Bar 
{
[Import]
public IFoo Foo { get; set; }
}


With MEF, I can simply implement an IConfiguration interface and import it wherever I need it. If I'm writing WPF or ASP.NET code, it's a simple matter in the implementation to parse an app.config or web.config file to load up the values. The consumers of this information, however, don't have to know (and quite frankly, don't care) how it got there. I have a setting for number of threads? A common pattern in Silverlight and WPF applications is to have a region for some functionality, and then page through multiple controls within that region. For example, a wizard might occupy the main region of the page but actually use four different controls for each of four different steps in the wizard. MEF makes it easy to handle this pattern using ImportMany. Another example is chain of responsibility and pipeline. The "weak link" in the chain is often that first "bootstrapper" class that has to wire in all of the links in the pipeline or chain of responsibility. The common implementation of this pattern is to have each link process and then conditionally pass processing along to the next link. With MEF, we can easily import many instances of ILink and then either chain them together or use an iterator or other means to walk through the processes. Adding a new link is as simply as building the implementation, then exporting the class.

The core concept of MEF

The essence of MEF paradigm is built upon the idea of needs and part that can be discovered (in order of satisfying the needs).  MEF assume that application is build from parts, each part may have needs to   consume other parts, or may be discover and consumed by other. In general parts consumers care about the contract and doesn't care about the parts implementation. MEF is using the following terms to address the above paradigm: Import: Define needs in term of Contract (the contract present the capabilities that is needed). Export: Exposing discoverable parts (that latter can be instantiate and consumed by the Import), the Export is also Contract based. Compose: is handle by the MEF engine, it responsible of putting the pieces together (discover and instantiate the matching Exports, and hand it to the Imports). As analogy you can think of it as having Guilds that publish its policy (shoemaker, tailor, ext…), and Peoples that declaring their professions, the MEF infrastructure apply the role of matching the Peoples to their suitable Guilds.

Strongly typed Metadata.

Jeremy Likness (microsoft MVP) said: "Of course, you might want to call classes in a particular order. Perhaps you export user controls and use an enumeration to specify where on the screen it belongs. Whatever your needs are, MEF allows you to supply strongly-typed metadata for your exports. For an example of this, take a look at MEF instead of Prism for Silverlight. There I use the metadata to specify the types of views and regions, then wire them together using the region management pattern introduced by Prism. Metadata can provide initialization information, routing information, and even priority information. For the Vancouver Winter Olympics, I built a synchronization tool that would scan primary and failover servers for live streaming. The tool generated lists of mismatched and/or missing files so the team at Microsoft could quickly react to ensure the integrity of the failover cluster and guarantee uptime. The tool created an XML document with the changes, then passed the document through a pipeline of modules. One module persisted the file to disk and updated a manifest. Another module would generate a CSV file, and yet another could email the document if certain alert criteria were met. I used MEF to pull in the modules, and metadata to tag the priority (for example, I wanted to persist the file to disk before specifying it as an attachment in the email program, so the module that saved the file had a higher priority than the module that would email it). When I needed another module, such as in testing, it was as simple as building it and exporting it to inject it into the pipeline".

Hello Meff example:

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
public interface IGreetings
{
void Hello();
}

[Export(typeof(IGreetings))]
public class Greetings : IGreetings
{
public void Hello()
{
Console.WriteLine("Hello world!");
}
}

class HelloMEF : IDisposable
{
private readonly CompositionContainer _container;

[Import(typeof(IGreetings))]
private IGreetings greetings = null;

public HelloMEF()
{
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
_container = new CompositionContainer(catalog);
var batch = new CompositionBatch();
batch.AddPart(this);
container.Compose(batch);

}

public void Run()
{
greetings.Hello();
}

public void Dispose()
{
_container.Dispose();
}

static void Main()
{
using (var helloMef = new HelloMEF())
helloMef.Run();
}
}
}

References

Get Microsoft Silverlight

Extensibility is a key design point for many applications such as the Microsoft Office applications with their plug-in model for extensibility. Silverlight 4 ships with a new framework, the Managed Extensibility Framework (MEF), which provides a flexible way of building extensibility into your applications with capabilities for discovering and composing extensions at run-time in a dynamic and loosely-coupled way. In this demo-based session we’ll take a tour around MEF and look at its capabilities for building extensibility into your applications and also how it can be used in implementing the Model->View->ViewModel (MVVM) pattern in Silverlight applications.

Krzysztof Cwalina http://blogs.msdn.com/kcwalina/
Mircea Troffin http://blogs.msdn.com/mirceat/
Wes Haggard http://weblogs.asp.net/whaggard/
David Kean http://davesbox.com/
Daniel Plaisted http://blogs.msdn.com/dsplaisted/
Glenn Block http://blogs.msdn.com/gblock/
Hamilton Verissimo http://blogs.msdn.com/hammett/ http://hammett.castleproject.org/
Nicholas Blumhardt http://blogs.msdn.com/nblumhardt/

Learn more about MEF

Read the MEF Programming Guide
Read about MEF in MSDN Magazine
Read our sample documentation
Architecture Overview
Visit the MEF Discussions
See our team Blogs
See field and industry blogs on MEF

Read reference documentation on MSDN, (more)

  • MEF 2 Preview 2 is live download
  • Sample: Using WebForms with MEF
  • MEF Preview 9 is live, download it here
  • If you want to know about MEF's underlying composition model, check out the new whitepaper on hosting the .NET composition primivites
  • MEF is now MS-PL, read about it here
  • MEF Contrib has launched. http://www.codeplex.com/MEFContrib
  • http://csharperimage.jeremylikness.com/2010/04/ten-reasons-to-use-managed.html

Summary

MEF provides you a lightweight bus-alike approach for your extensions. By hosting MEF, you are delegating this discovery system to MEF, and it provides you a rich Meta Data to be used. The Export - Import model indeed looks very similar to Publisher and Subscriber model in this sense. MEF is by no means a replacement to today’s IoC containers, nor to System.Addin . It aims to be a reusable solution to provide a common base for the heavy lifting code of extensible applications, so we (hopefully) will need to worry less about extensibility concerns of the application. MEF is part of .NET 4.0 and its not application specific you can use it any .NET Application like  Windows Forms, WPF , SilverLight, ASP.NET etc. Have you already tried MEF (Managed Extensibility Framework) in .NET 4.0?

Comments (3) -

  • Agafonov Slava

    10/18/2010 6:22:12 PM | Reply

    What do you think about Managed Extensibility Framework in .NET 4.0?

  • Mikhail

    10/19/2010 12:32:33 AM | Reply

    MEF looks like Ninject (I have never used any of them), what is the difference? The article of Jeremy you linked is titled "MEF instead of PRISM". But actually the newest version of PRISM is using MEF!

  • Agafonov Slava

    11/23/2010 2:44:15 PM | Reply

    Michail, I like both patterns. But PRISM is ugly when project is quite simple. It is better to use just MVVM without anything. Keep it simple.

Loading