Derik Whittaker : MEF

Speaking on MEF at the L’viv .Net Users Group

Derik Whittaker — Wed, 30 Jun 2010 11:18:40 GMT

I just confirmed that when I am over in L’viv Ukraine working with our team there (btw, they are a kick @ss team) I will be speaking at the L’viv .Net Users group. The topic of the night will be MEF (on codeplex).

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.

If you are in the area and are up for an English based session on MEF please stop by and say hello.

For more information check out http://dotnetug-lviv.blogspot.com/

Quick Lap Around MEF at the Raleigh VS 2010 Road Show

Derik Whittaker — Thu, 03 Jun 2010 00:02:53 GMT

Today at the Raleigh VS Southern Road Show which was put on by Brian Hitney and Glenn Gordon I had a chance to do a 20 minute lightning talk on MEF. Because I only had 20 minutes, my talk focused on explaining the ‘what and the why’ along with providing 2 (had 3 but only got through 2 of them) straight forward examples on how to use MEF.

I thought it would be good to attach my slide deck (all 6 slides) along w/ my sample code here

Thanks again Brain and Glenn, great show.

Till next time,

Providing Metadata to your MEF exports

Derik Whittaker — Sun, 07 Mar 2010 01:07:24 GMT

Many months ago I created a post on how to get started with MEF. Ever since then I have been meaning to get this post (and others) about about how to get up and running quickly with MEF.

In this post will demonstrate how to provide Metadata (custom values which can help provide context) information to your Exported item. Why should you care about Metedata? Below is a great reason from the MEF site on codeplex

Declaring Exports explained the basics of parts exporting services and values. In some cases it’s necessary to associate information with exports for a variety of reasons. Commonly it’s used to explain about the capabilities of an specific implementation of a common contract. This is useful to allow imports to either constraint the export that can satisfy it, or to import all available implementations at the time and check their capabilities in runtime before using the export.

Before we get rolling:

What I am going to show in this post is how to create a custom Export Attribute. It is possible to expose Meta via the build in ExportAttribute, but the built in mechanism has a few short comings:

Not discoverable
Not strongly typed
Compiler cannot validate the data content

Lets get rolling:

Pre-Step 1: Taking a look at the Class which we will mark as a Export

    public interface IPlugin
    {
        string PluginAction();
    }

    [Export(typeof(IPlugin))]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

Step 1: Defining the interface which will represent your

In order to create discoverable Metadata you will first want to create an interface which will represent your metadata. Below is my interface.

    public interface IPluginMetaData
    {
        string Name { get; }
        string Version { get; } 
    }

We will later use this interface when we define and use our custom Export Attribute. The main reason for creating this attribute is now the compiler has a hard wired way to know exactly what type of data is being exposed in your Metadaa

Step 2: Defining your custom ExportAttribute Attribute

Now that we created our interface to give us strong typing and discoverability we need to create a custom attribute which will allows the MEF engine to know we have Metadata to expose

    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    public class PluginMetadataAttribute : ExportAttribute
    {
        public PluginMetadataAttribute( string name, string version)
            : base(typeof(IPluginMetaData))
        {
            Name = name;
            Version = version;
        }

        public string Name { get; set; }
        public string Version { get; set; }
    }

When looking at the code above there are 3 things to pay close attention to

You need to make a call into the base constructor of the ExportAttribute and provide it the type of your interface which defines your Metadata
You need to mark your attribute with the [MetadataAttribute] (which is part of MEF)
You need to mark the usage type of your attribute. I am not 100% why this is needed (Glenn, you out there with an answer???)

Step 3: Providing your Metdata to your Exported Class

    [Export(typeof(IPlugin))]
    [PluginMetadata("Default", "1.0.0.0")]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

The code above is the same as the code we saw in pre-step 1, but this time we have marked the class with our custom Metadata attribute. We have now officially provided our Metadata to our Export…. But how do we get this information out of MEF?

Step 4: Setting up your [ImportMany] to use the Metadata

If you are using an ImportMany (this should also work on an Import, but I have never tried) most likely you are pushing your Exports into a IList or IEnumerable. If this is the case, your changes are pretty minor. Below is what you need to do in order to have your Metadata loaded.

[ImportMany(typeof(IPlugin), AllowRecomposition = true)]
private IList<Lazy<IPlugin, IPluginMetaData>> _loadedIPlugins = new List<Lazy<IPlugin, IPluginMetaData>>();

If you have not seen the Lazy keyword, you are not alone. This is new to .Net 4 and this provides Lazy initialization support to the framework. (part of the System namespace). One key thing to understand here though is that the Lazy keyword out the box is only Lazy<T>, but the Lazy we are using is Lazy<T, M>. This extended version of Lazy lives in the MEF assemblies (System.ComponentModel.Composition) and will need to be referenced to use.

Step 5: Using the Metadata

Once you have the Export loaded into your container (which by the way does not need to change to have this work) you can access your container by selecting the .Metadata property on your instance of the export. The image below shows it in action.

As you can see, exposing and using Metadata via MEF is a snap.

Till next time,

MEF and decrypting LoaderExceptions

Derik Whittaker — Sun, 31 Jan 2010 14:51:02 GMT

Have you ever received the following exception while using MEF?

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

if you have received this error did you scratch your head and wonder ‘what the F does this mean’? Well the long and short of it is this. This means that while trying to load an Export there was a dependency which could not be found during reflection.

The quick way to determine the cause of the error is to do as the image below shows:

What I would suggest is to wrap your MEF logic inside of a try-catch and explicitly catch ReflectionTypeLoadException. Inside of your catch add some logic as such (just a PoC, copy-paster beware).

catch (ReflectionTypeLoadException tLException)
{
    var loaderMessages = new StringBuilder();
    loaderMessages.AppendLine("While trying to load composable parts the follwing loader exceptions were found: ");
    foreach (var loaderException in tLException.LoaderExceptions)
    {
        loaderMessages.AppendLine(loaderException.Message);
    }

    // this is one of our custom exception types.
    throw new PluginLoadingException(loaderMessages.ToString(), tLException);
}

As you can see when you look at the LoaderExcpetions collections from my image above I had forgotten to reference AutoMapper in my plug-in and all hell broke lose (btw, no idea how this even compiled, but that is a different post).

Hope this helps.

Till next time,

Enabling Recomposition in MEF (Preview 8)

Derik Whittaker — Mon, 16 Nov 2009 11:05:00 GMT

In my previous post (here) I showed you how to setup and get running with MEF. However, what I left out from that post is how to setup MEF to allow ‘recomposition’, which is the fancy way of saying to allow your application to discover new plugins at run time. Allowing your application to discover new plugins while still running could be a major feature as it could allow you to add/change the behavior without the need to restart. One useful scenario for this could be adding a new rules for a rules engine on the fly.

Goal of this demo?

Show you how you can add in the ability to rediscover exports at runtime with MEF.

What is needed?

If you have not already done so head out to http://mef.codeplex.com/ and grab the latest source download. More than likely you will need to download and compile all the source in order to get working binaries (hey, it is a preview after all). Once you have compiled the source you need to grab the output from the ComponentModel project (assembly name is System.ComponentModel.Composition) and include this into your project.

Also, if you have not taken a look at my previous post (here) please do so now as I will be building upon that post.

Putting it together?

Configuring your imports to allow recomposition.

This is one of the great parts of MEF, performing this configuration is CAKE, all you need to do is modify the attribute you have place on your collection as follows

[ImportMany(typeof(IRule), AllowRecomposition = true)]
internal IList _rules { get; set; }

After you have added the ‘AllowRecomposition’ attribute you are pretty much done. However, if you would like to be notified (via an event) each time recomposition happens you can do as follows

public void Init()
{
    try
    {
        var catalog = new AggregateCatalog();
        var container = new CompositionContainer( catalog );
        var batch = new CompositionBatch();
        batch.AddPart( this );

        catalog.Catalogs.Add( new AssemblyCatalog( Assembly.GetExecutingAssembly() ) );

	// this is the new part
        catalog.Changed += catalog_Changed;

        container.Compose( batch );
    }
    catch ( CompositionException compositionException )
    {
	// testing
        throw;
    }
}

void catalog_Changed( object sender, ComposablePartCatalogChangeEventArgs e )
{
	// do something here
    	var x = "";
}

Wrapping it up

As you can see, setting up MEF for recompisition is cake and is really only requires a modification to one line of code.

Till next time,

Simple Kick Start Example using MEF (Preview 8)

Derik Whittaker — Tue, 27 Oct 2009 10:34:00 GMT

If your application needs extension points what do you do? Building a plugin based system is not cutting edge, it is not rocket science. However, it does take a little effort and can be a bit painful depending on your implementation. The guys at MS (Glen Block and crew) has been working on this kickin framework for about a year now called the Managed Extensibility Framework (most commonly known as MEF). The core goal of MEF is to simplify the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.

There are a metric crap-ton of samples out on the net which show how to get running with MEF, however many of the posts are based off of older previews and most are also incomplete in terms of the code they show you on screen. What I would like to do is provide a detailed how-to on getting your first (simple) MEF application up and running.

Goal of the demo code?
For this demo code we are going to put together a very simple rules plug-in engine. The goal is to be able to add in a new IRule at any point and have your application pick it up.

What is needed?
If you have not already done so head out to http://mef.codeplex.com/ and grab the latest source download. More than likely you will need to download and compile all the source in order to get working binaries (hey, it is a preview after all). Once you have compiled the source you need to grab the output from the ComponentModel project (assembly name is System.ComponentModel.Composition) and include this into your project.

Putting it together?

Creating the rule Interface : IRule
This is needed because in order to define a plug-in you need to define what that plug-in looks like.

public interface IRule
{
    void DoIt();
    string Name { get; }
    string Version { get; }
    string Description { get; }
}

Creating a rule instance (or two)
Now that we have our rule interface we need to create specific instances of the rule and mark them for export. Marking them for Export simply entails adding a attribute provided by the MEF framework and this attribute allows you to describe your plug-in to the MEF framework so it can pick it up.

[Export( typeof( IRule ) )]
internal class RuleInstance1 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 1"; }
    }

    public string Version
    {
        get { return "1.0.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

[Export( typeof( IRule ) )]
public class RuleInstance2 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 3"; }
    }

    public string Version
    {
        get { return "1.1.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

Creating the holder for all your plug-ins
In order to have your application know about the plug-ins that MEF has found you need to define a storage location for them. We will do this by creating a property of IList<IRule> which will hold each instance. When we create this storage location we need to tell MEF that we are going to use this as a storage location and to do this you need to mark it with the ImportMany (use this attribute if you want a collection, use Import for only a single instance) attribute. This is another special attribute provided by the MEF framework.

[ImportMany( typeof( IRule ) )]
internal IList<IRule>: _rules { get; set ;}

Creating the logic to load the plugin
Now that we have all the heavy lifting out of the way in terms of defining our Imports and Exports it is time to setup our application to consume the data. It is here where you tell MEF where to look to find your exports (plug-ins) and what to do with them once you have found them.

public void Init()
{
    var catalog = new AggregateCatalog();
    var container = new CompositionContainer( catalog );
    var batch = new CompositionBatch();
    batch.AddPart( this );
    // because all our types are in the same assembly we simply use the current one.    
    catalog.Catalogs.Add( new AssemblyCatalog( Assembly.GetExecutingAssembly() ) );
    container.Compose( batch );
    foreach ( var rule in _rules )
    {
        Debug.WriteLine( rule.Name );
    }
}

Wrapping it up
As you can see getting a simple example of MEF up and running is a pretty simple task (great job MEF team). You should be able to get this up and running in about 10 minutes. You should also have all the code you need in order to get this running. I hope this helps kick-start someone’s learning and adoption of MEF.

Till next time,