Updated 2009-04-08 11:48:
Thanks to Eric Nelson who included this as the Feature Article in today's MSDN UK Newsletter. (updated on the web soon, I hope!).
Also, and with perfect timing, the MEF Team have just released MEF Preview 5. Enjoy.
Joel
In this article, I will provide a basic overview of the Managed Extensibility Framework (MEF), and detail a practical sample of providing extensibility in your application.
But what is it? And why is using it a good idea?
According to its project web site, MEF is “a new library in .Net that enables greater reuse of applications and components.”[1]
MEF provides an engine that will dynamically extend your .NET application with plug-ins at run-time. You define the requirements to extend your application by decorating the classes in your core application with MEF’s attributes. Plug-ins can then be created as classes that will satisfy these requirements, again using MEF’s attributes to indicate what requirements the plug-in class will satisfy.
Currently in open development, the January 2009 release (Preview 4) is licensed under the MS-PL – which means you can use it right away for real projects. There is already a strong community grown up around MEF, including a Contrib project and plenty of articles on the web – but getting started with MEF can be a daunting prospect.
Glenn Block put it very succinctly:
“In MEF everything is an extension, everything is extensible (extensions themselves included).”[2]
Let’s look at a simple sample (download the code here) - a Login processing module which needs to allow extentions to the processing of a login request with custom code, without re-writing the login code and without the login module referencing the extensions.
To implement the extensibility for the login module, we define an interface that describes the functionality that a Login Extension should provide (ILoginExtension), an “extension point” in login code at the point where logically the checks should occur (in the sample this is in the LoginHelper class), and finally a LoginExtensions property (again in the LoginHelper) that will contain the extensions that MEF provides.
What makes MEF so easy is that the interface (ILoginExtension) exposed by the requirement is the only piece of shared information. MEF scans all assemblies in your application (and / or specific directories as you choose) for plug-ins that will satisfy the requirement and calls the setter for the LoginExtensions property, “injecting” the list of extensions so that the code at the extension point merely has to iterate the list and call the implementation method on each extension.
This magic happens when, in the LoginHelper’s constructor, we use MEF to generate a catalog of all extensions (classes decorated with an Export attribute) and requirements (classes with properties decorated with an Import attribute). Better still, the catalog can watch the file system for new plug-ins being added on the fly.
This catalog is then passed to the composition engine (an instance of the MEF CompositionContainer class) and the container statisfies all the requirements (Imports) found with the matching extensions (Exports).
Now we’ve looked at MEF in overview, let’s dive into our sample code, starting with the ILoginExtension interface:
public interface ILoginExtension
{
void LoginEx(ref Session session);
}
So our extension point will call the LoginEx method of any extensions, passing in a reference to the current user’s session. The LoginEx method can then do any additional checks it needs and throw an exception (or modify the session information) based on whatever its own requirements are.
Next the extension point itself:
public Session Login(string username, string password)
{
// Get a session - this is abstracted via MEF too.
var session = SessionProvider.GetSession(username, password);
// =============================================
// EXTENSION POINT
// =============================================
// process all the extensions
if (LoginExtensions != null)
{
Console.WriteLine(string.Format("LoginHelper: Found {0} extensions...",
LoginExtensions.Count()));
foreach (var extension in LoginExtensions)
{
extension.LoginEx(ref session);
}
}
// =============================================
// END EXTENSION POINT
// =============================================
return session;
}
This code is as simple as it comes – after we do our initial login check and have a session, just iterate the extensions, calling them each in turn.
The LoginExtensions property is the point at which MEF will inject the extension instances:
[Import(AllowRecomposition = true)]
public IEnumerable<ILoginExtension> LoginExtensions { get; set; }
Note that MEF automatically understands that if a module requires an IEnumerable of a type, then it is to inject a list of class instances that satisfy that requirement into the property. If the requirement is for a single instance, then just the first matching extension will get injected. So we could also abstract how a session is created (for example, from a database, or via a web service), and the LoginHelper can indicate its need for a provider with a property for that:
[Import]
public ISessionProvider SessionProvider { get; set; }
In the sample, this composition logic is encapsulated in a static ExtensionHelper class that provides a single container of all the Imports and Exports, as well as a simple method to allow a module to compose itself.
public static class ExtensionHelper
{
...
public static void Compose(object compositionTarget)
{
// configure our Imports so that we've loaded any plugins.
var batch = new CompositionBatch();
batch.AddPart(compositionTarget);
using (var container = GetCompositionContainer())
{
container.Compose(batch);
}
}
...The Compose method is the heart of the helper – it retrieves the composition container from a helper method, then instructs that container to satisfy any requirements of the object passed into it.
We centralise our container generation so that the catalog of imports and exports is generated only once – parsing all the assemblies in a large project can take a little time.
public static class ExtensionHelper
{
private static AggregateCatalog _catalog;
private static object _padlock = new object();
public static CompositionContainer GetCompositionContainer()
{
if (_catalog == null)
{
lock (_padlock)
{
_catalog = new AggregateCatalog();
// Add the current executable
_catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
// Add all the assemblies in the executable's directory
_catalog.Catalogs.Add(new DirectoryCatalog(".", false, "*.dll"));
// add any plugins assemblies
if (PlugInsDirectoryExists)
{
_catalog.Catalogs.Add(new DirectoryCatalog(PlugInsDirectory, true, "*.dll"));
}
}
}
// finally, build the composition container
var container = new CompositionContainer(_catalog);
return container;
}
...
}
You will notice that we add three “sub-catalogs” to our application’s plug-in catalog:
- A catalog containing any imports and exports found in the current executing assembly
- A catalog containing imports and exports from any other assemblies found in the current working directory. This is a “static” catalog.
Note: For windows services & ASP.Net, the working directory is NOT the executable’s installation directory, so you may need to compensate!.
- A catalog containing imports and exports from any assemblies found in a specific “plug-ins” directory.
This catalog is “dynamic”, indicated by the true flag passed into its constructor, and will “watch” the plug-ins directory for any assemblies being added or removed. The next composition that happens would then automatically pick up any new plug-ins – a really powerful feature.
We cache the catalog so that the assembly resolution happens only once, but create a new composition container each time just to be on the safe side and avoid any interactions between objects being composed.
With this helper class available, the LoginHelper’s constructor becomes about as simple as you could hope for:
public LoginHelper()
{
ExtensionHelper.Compose(this);
}
Finally, we can implement an extension in a completely separate assembly if required, just by implementing the requirement interface (e.g. ILoginExtension) and decorating the class appropriately. So we can implement a FooLoginCheckExtension plug-in class thus:
[CompositionOptions(CreationPolicy = CreationPolicy.NonShared)]
[Export(typeof(ILoginExtension))]
public class FooLoginCheckExtension : ILoginExtension
{
public void LoginEx(ref Session session)
{
Console.WriteLine(string.Format(" Foo: Processing {0}", session.Guid));
}
}
MEF also is recursive – if any extensions need providers, or have other extension points themselves, these too will be satisfied when the MEF composes the LoginHelper. This means you COULD write a completely interface-driven system, where every component is bound in dynamically using MEF.
Even for this simple case, the MEF provides an elegant and above all SIMPLE way of defining and implementing extensibility within your application. Use it once, and you’ll be using it again and again to implement extension points in your code that will make it much more flexible.
On a final note, it should be stressed that MEF is NOT an Inversion of Control container[3] - it targets purely one goal: Dependency Management. But it does this well, and as such is a worthy addition to any developer’s toolset.
[1] http://www.codeplex.com/MEF
[2] http://codebetter.com/blogs/glenn.block/archive/2008/09/25/what-is-the-managed-extensibility-framework.aspx
[3] http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx
