Brad Abrams : MEF

Silverlight 3 Navigation: Dynamically Loaded Pages… Now MEF Powered!

BradA — Sat, 01 Aug 2009 01:28:00 GMT

Recently David Poll posted a very cool technique for navigating to dynamically loaded pages and on demand downloading of pages in a Silverlight 3 application . It was very cool but the explicit wire up of each page can be a pain in large applications. So having just posted about MEF on Silverlight, I thought this was a great fit. The Managed Extensibility Framework (MEF) is all about discovering and wiring up components and Silverlight 3 Navigation has some very interesting components. But before I could get it done, our Test Manager, Dinesh Chandnani beat me to it. He wrote this very cool example app that I extended just a bit.

Download the all the source code and check out an live sample…

The model is very simple. You just create a page (via the Silverlight Page item template) and put metadata on them saying how to navigate to it. The page can be in the same XAP or different XAP. No need to wire them up.

For example, for a page in the same XAP, you just create a page and add some metadata to it

   1: [PageMetadata(Content = "page1", NavigateUri = "/page1")]

   2: public partial class Page1 : Page

   3: {

For a page in a different assembly, possibly delay loaded or conditionally loaded:

   1: [PageMetadata(Content="delayloaded",

   2:     NavigateUri="/DelayLoadedPages;component/DelayLoadedPage.dyn.xaml")]

   3: public partial class DelayLoadedPage : DynamicPage

   4: {

Pretty much the same, but we use the packURI syntax and David Poll’s Dynamic page class\pattern (see his blog post above for more information).

If you want to load pages from an external assembly, you do need to explicitly load that assembly. But this is pretty easy to do and it can be done at any point in the application. When the user logs in as in an admin role, when advanced functionality is required, after initial startup of the application, etc. The page simply appears in the nav bar when it is downloaded and running. For example, I extended Dinesh’s code by adding an assembly that was loaded when a button is clicked. The code is simple:

   1: private void Button_Click(object sender, RoutedEventArgs e)

   2: {

   3:     Package.DownloadPackageAsync(new Uri("DelayLoadedPages.xap",

   4:         UriKind.Relative), DownloadCompleted);

5:

   6: }

   7: private void DownloadCompleted(AsyncCompletedEventArgs e, Package p)

   8: {

   9:     var app = App.Current as SilverlightMEFNavigation.App;

10:

  11:     if (!e.Cancelled && e.Error == null)

  12:         app.PackageCatalog.AddPackage(p);

  13: }

When the button is clicked, we download kick off an async download of the XAP (line 3-4). Then when it is downloaded it we add it to the catalog the nav bar is tied to in line 12.

Now, how does all this work? There are afew parts really.

First we define the PageMetadataAttribute in the main assembly. All the pages will have to reference this, so you might want to factor it out into its own assembly..

   1: [MetadataAttribute]

   2: [AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]

   3: public class PageMetadataAttribute  : ExportAttribute

   4: {

   5:     public PageMetadataAttribute() : base(typeof(FrameworkElement)) { }

   6:     public string NavigateUri { get; set; }

   7:     public string Content { get; set; }

8:

   9: }

A few notes:

Line 1: We set this up as a MEF Metadata attribute.. this enables the MEF engine to get composition information from this attribute
Line 2: We set this up such that it can be applied only once per type. MEF uses this as a hit on how to compose it.
Line 3: we derive from ExportAttribute, this enables us to completely hide the MEFness out of the picture… folks writting pages don’t need to know MEF is under the covers at all.
Line 4: Say that this attribute will be used on FrameworkElements, a hit to MEF on how to type things.
Lines 6-7: just set up the attribute interface we want.

In MainPage.cs, we have some code that populates the nav bar as new pages are discovered.

   1: [Export]

   2: public partial class MainPage : UserControl, IPartImportsSatisfiedNotification

   3: {

   4:     [ImportMany(AllowRecomposition = true)]

   5:     public ObservableCollection<Lazy<FrameworkElement, IPageMetadata>> Pages = null;

We have a Pages collection that we have marked with AllowRecomposition, which means its value’s can change over the life of the application (such as when a new package is added as I showed above).

Then we simply update the links whenever new items are available in the Page collection.

   1: private void UpdateLinks()

   2: {

   3:     if (Pages == null || Pages.Count <= 0)

   4:         return;

5:

   6:     for (int i = 0; i < Pages.Count; i++)

   7:     {

   8:         if (LinksStackPanel.Children.Where(u=>(u is HyperlinkButton)

   9:             && (u as HyperlinkButton).Content.ToString()

  10:                     == Pages[i].Metadata.Content).FirstOrDefault() != null)

  11:             continue;

  12:         HyperlinkButton hb = new HyperlinkButton();

  13:         hb.Style = ((App)Application.Current).Resources["LinkStyle"] as Style;

  14:         hb.Content = Pages[i].Metadata.Content;

  15:         hb.NavigateUri = new Uri(Pages[i].Metadata.NavigateUri, UriKind.Relative);

  16:         LinksStackPanel.Children.Add(hb);

  17:     }

  18: }

Notice in line 12-16 we are dynamically creating the Xaml elements to add into the tree.

The final bit of code we added was in App.cs to set MEF..

   1: private void Application_Startup(object sender, StartupEventArgs se)

   2: {

   3:     AggregateCatalog aggregateCatalog = new AggregateCatalog();

   4:     AssemblyCatalog ac = new AssemblyCatalog(Assembly.GetExecutingAssembly());

   5:     aggregateCatalog.Catalogs.Add(ac);

   6:     aggregateCatalog.Catalogs.Add(PackageCatalog);

   7:     // Load any package dynamically

   8:     Package.DownloadPackageAsync(new Uri("AdditionalPages.xap", UriKind.Relative), DownloadCompleted);

   9:     CompositionContainer container = new CompositionContainer(aggregateCatalog);

  10:     this.RootVisual = container.GetExportedValueOrDefault<MainPage>();

  11: }

Here we setup the catalog to enable MEF to look for pages in the current assembly and in an assembly we download dynamically after the app is up and running. Line 8 sets up the call to the handler below when the page has been downloaded…

   1: private void DownloadCompleted(AsyncCompletedEventArgs e, Package p)

   2: {

   3:     Thread.Sleep(1000);

   4:     if (!e.Cancelled && e.Error == null)

   5:         PackageCatalog.AddPackage(p);

   6: }

For such as simple example on my dev machine the page downloads immediately so you can’t really tell.. so I added a brief delay so you can see it pop it easier. So the Thread.Sleep() in line 3 is there to demo better… I highly recommend removing it in production code.

That is all there is to it! A very simple solution.

For more information see:

Eric Mok’s excellent video walk through of MEF
My MEF on Silverlight Post
David’s Silverlight Navigation dynamic loading post

Simple Example of Managed Extensibility Framework (MEF) in Silverlight

BradA — Mon, 20 Jul 2009 18:17:00 GMT

As you may have heard, we recently shipped MEF support of Silverlight in our CodePlex drop.. I wanted to give you a very simple introduction to MEF and how to use it in Silverlight. This example will show how to use lose coupling, dependency injection and delay loading of components. This is also an update to my Simple MEF example from a few months ago as just about everything here applies to WPF, WinForms and ASP.NET apps as well.

The demo requires (all 100% free):

Also, download the full demo files…

Let’s start with the very cool Silverlight Navigation Application

Setting up The Problem

This is a very simple example just to show how the technology works. Let’s say you want to put some string a TextBlock… As a bigger example, think of pages in an application or components in a portal, etc, etc.

Replace the contents of the ContentStackPanel in Home.xaml with a ListBox and set up some binding.

<StackPanel x:Name="ContentStackPanel">

    <TextBlock Text="{Binding Mode=OneWay}"></TextBlock>

</StackPanel>

Then in codebehind we set up the datacontext:

public Home()

    InitializeComponent();

    LayoutRoot.DataContext = "Hello World!";

Of course, we get exactly what we’d expect….

Now there are some problems with this.. For example, the value of the string is tied up in the constructor, i might want to have that factored out so that it can be accessed separately.

   1: public partial class Home : Page

   2: {

   3:     public Home()

   4:     {

   5:         InitializeComponent();

6:

   7:         var message = new SimpleHello();

   8:         LayoutRoot.DataContext = message;

   9:     }

  10: }

11:

  12: [Export("Message")]

  13: public class SimpleHello

  14: {

  15:     public override string ToString()

  16:     {

  17:         return "Hello World!";

  18:     }

  19: }

This will certainly do the trick at some level, but there is still something odd about lines 7 and 8… I am creating an instance of exactly this type which locks the functionality down to one instance. That means the type has to be in my codebase. What if I’d like to enable some separation? maybe get that Message from a variety of sources based on config, the user preference, the role of the user, etc.

Enter MEF

Let’s see how MEF can help.. First we need to add a reference to the MEF assembly (System.ComponentModel.Composition.dll) that is found in the MEF_Preview_6\bin\SL3 folder of the latest bits. I copied it into the bin directly of the project (which is hidden by default) and added a reference to it from there.

As Jason Olson says: MEF is as easy as 1, 2, 3…Export It, Import It, and Compose It…

So the first step is Export it.. so let’s export the SimpleHello type… this is easy enough to do by simply putting an Export attribute on the type and specifying the contract name.

   1: [Export("Message")]

   2: public class SimpleHello

   3: {

Next step is to Import it, so let’s import some type to databind to.

[Import("Message")]

public object Message;

public Home()

    InitializeComponent();

    LayoutRoot.DataContext = Message;

That looks very clean… I simply say what I have (an export) and what i need (an import). But who does the wiring up? Well, we have one more step… Compose It:

Add the following lines to the constructor…

   1: var catalog = new PackageCatalog();

   2: catalog.AddPackage(Package.Current);

   3: var container = new CompositionContainer(catalog);

   4: container.ComposeParts(this);

Line 1 shows off our new PackageCatalog that just new for this Silverlight release. Catalogs generally tell MEF where to look to find stuff to put in the container. Line 2 adds the current XAP to the catalog.. later we will show how to add XAPs that are asynchronously downloaded via a different catalog.

Line 3 creates a Composition container-- this is effectively the container that all the different parts will be wired up together.

Line 4 composes… that is wires up all the imports and exports. After this line, all imports are fully satisfied or an exception is raised.

Running the app has it work exactly the same way, but now loosely coupled.

That is great, but using strings such as “Message” to identify contracts is fraught with problems. It turns out the CLR already has a pretty well developed way to deal with contracts and that is CLR Types. So it is recommended in most cases that you use CLR Types to indicate the contracts. To do this, let’s define an IMessage interface in a separate assembly so that it can be shared by different assemblies contributing components.

Add a new project, and call it ContractsClassLibrary

Add a single type.. IMessage… right now it has no members, it is effectively a marker interface. We could of course define some methods if they are needed.

namespace ContractsClassLibrary

    [InheritedExport]

    public interface IMessage

Notice we put the new InheritedExport attribute on this type… this means that any type that implements this interface will automatically be exported as type IMessage. This keeps the “MEF goo” out of your public object model.

Now, add a reference to ContractsClassLibrary from the MyMEFApp project and let’s look at how that SimpleHello type changes..

public class SimpleHello : IMessage

    public override string ToString()

        return "Hello World";

Notice, no MEF goo on it…

Fun and the app and you get the exact same results… but this time our contract is a CLR type rather than a string.

Now, let’s say I had more than one message to show.. No problem, i just add another instance to the container with the same export.

public class SimpleHola: IMessage

    public override string ToString()

        return "Hola";

Hit F5 and… Wham.. I get an error..

(Side note: if you get a less helpful message that says “navigation failed”, in MainPage.cs change the ErrorWindow to show the inner exception…)
private void ContentFrame_NavigationFailed(object sender, NavigationFailedEventArgs e)
{
    e.Handled = true;
    ChildWindow errorWin = new ErrorWindow(e.Exception.InnerException);
    errorWin.Show();
}

As these things go, it is actually a pretty helpful error message:

The composition remains unchanged. The changes were rejected because of the
following error(s): The composition produced a single composition error. 
The root cause is provided below. Review the CompositionException.Errors 
property for more detailed information.

1) More than one exports were found that match the constraint 
'((exportDefinition.ContractName = "ContractsClassLibrary.IMessage") 
&& (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") && 
"ContractsClassLibrary.IMessage".Equals(exportDefinition.Metadata.get_Item("ExportTypeIdentity"))))'.

Resulting in: Cannot set import 'MyMEFApp.Home.Messages (ContractName="ContractsClassLibrary.IMessage")' on part 'MyMEFApp.Home'.
Element: MyMEFApp.Home.Messages (ContractName="ContractsClassLibrary.IMessage") --> MyMEFApp.Home


   at System.ComponentModel.Composition.CompositionResult.ThrowOnErrors(AtomicComposition atomicComposition)
   at System.ComponentModel.Composition.Hosting.ComposablePartExportProvider.Compose(CompositionBatch batch)
   at System.ComponentModel.Composition.Hosting.CompositionContainer.Compose(CompositionBatch batch)
   at System.ComponentModel.Composition.AttributedModelServices.ComposeParts(CompositionContainer container, Object[] attributedParts)
   at MyMEFApp.Home..ctor()

Basically it is saying that we were only expecting one message, and the container has more than one..

The easy solution here is to accommodate more than one Message..

[ImportMany]
public ObservableCollection<IMessage> Messages { get; set; }

and let’s change the UI control to a ListBox…

<ListBox ItemsSource="{Binding Mode=OneWay}"></ListBox>

Run it and we get both messages..

Another thing that is really cool about MEF is that we do full composition, that is even the parts in the container can have dependencies that are satisfied and runtime. For example, let’s take out SimpleHello class and say we wanted to externalize providing the actual text… we could do that easily enough.

   1: public class SimpleHello : IMessage

   2: {

   3:     [Import("Text")]

   4:     public string Text { get; set; }

   5:     public override string ToString()

   6:     {

   7:         return Text;

   8:     }

   9: }

10:

  11: public class TextProvider

  12: {

  13:     [Export("Text")]

  14:     public string Text { get { return "Hello World!"; } }

  15: }

We simply export the text from a provider class and import it into our SimpleHello class. (I am using the string contract name here just for simplicity, you could of course define an IText interface and use it exactly as we showed above.) Notice the by product of this pattern is that each class gets very focused and specialized in what it deals with. SimpleHello now is just about overriding ToString() and doesn’t care a thing about where it gets the message from. That means we could easily add another way to offer text for binding… How about as a button?

   1: public class ButtoHello: Button, IMessage

   2: {

   3:     [Import("Text")]

   4:     public string Text {

   5:         get {

   6:             return this.Content.ToString();

   7:         }

   8:         set

   9:         {

  10:             this.Content = value;

  11:         }

  12:     }

  13: }

This is time, we use the same text, but rather then ToString(), we use it to set the content property of the button. This is a great example of a single instance exporting and importing dependencies.

OK – that is cool… but all this is in the same project.. what if we wanted a bit more separation? Well, the first step we could do is put some parts into a separate assembly, but deployed with the same XAP.

We will need to reference our ContractsClassLibrary project.

Then just add a couple of classes that export “Message”

public class Class1 : CheckBox, IMessage

    public Class1()

        this.Content = "From Assembly: ma kore?";

public class Class2: IMessage

    [Import("Text")]

    public string Text { get; set; }

    public override string ToString()

        return "From Assembly:" + Text;

Notice, we can again, import the text optionally if we’d like. This shares the exact same instance with any other type that imports it.

Then we add a reference to this library from the main Silverlight app… this puts the library in the XAP

Now, run it and we get some more items..

Now the final step is to load the parts, asynchronously from the server.. This allows you to have components that are downloaded ONLY when they are needed. It also enables much faster startup time where the core of the app can start up and features can light up as they are downloaded. This is a much better experience than a long “loading…” screen.

To do this, we need to create a library that is packaged as a XAP.. the best way to do that is to create a new Silverlight Application, and just delete the MainPage.xaml…

Then we want to host this in the same web site.. .Notice you could host it in a different website, but you would then need to use the Silverlight networking stack’s mechanism to get at non-originating servers.

You can go ahead and delete MainPage.Xaml and App.Xaml so we don’t get confused and add a Class1.cs file.

We will also need to add a reference to our ContractsClassLibrary project

Then just define a class an Export it..

public class Class1: IMessage

    public override string ToString()

        return "From Dynamically Loaded: ciào";

You could optionally import the same Text property if you’d like as well..

public class Class2 : ComboBox, IMessage

    [Import("Text")]

    public string Text

set

            this.ItemsSource = value.ToCharArray();

Now we need to go back into the main app and tell it where to dynamically load this from.

   1: public Home()

   2: {

   3:     InitializeComponent();

4:

   5:     var catalog = new PackageCatalog();

   6:     catalog.AddPackage(Package.Current);

7:

   8:     Package.DownloadPackageAsync(

   9:         new Uri("DynamicallyLoadClassLibrary.xap", UriKind.Relative),

  10:        (sender, pkg) => catalog.AddPackage(pkg)

  11:     );

12:

13:

  14:     var container = new CompositionContainer(catalog);

  15:     container.ComposeParts(this);

16:

17:

  18:     LayoutRoot.DataContext = Messages;

  19: }

As you can see, we inserted lines 8-11 to deal with this new dynamically loaded XAP. Here we are simply doing delay loading, but you could wait and load on some user action (clicking a button for example) or you could load based on who is logged in, what functionality they prefer, what role they are in, etc.

In line 9, we create a URI pointing to our XAP.. in this case from the same server, but it could be from any server assuming the right policy files are in place.
In line 10, we are handling the callback.. remember this is an async call. When the call completes, we simply add any parts discovered to the catalog.

Now, the async nature of this is interesting, because effectively we are changing a programs dependencies mid-flight. Not always a good idea, so it is something you need to opt into.

[ImportMany("Message",AllowRecomposition=true)]

public ObservableCollection<object> Messages { get; set; }

And now we run and it looks great!

So, what have we seen? You can use MEF to improve the quality and structure of your code so that classes have a single set of responsibilities. MEF also makes it easy to optionally download components on demand.

Check out the completed example.

We’d love to hear what you think!

Managed Extensibility Framework (MEF) Preview 6: V1 Feature Complete Silverlight Support and Much More!

BradA — Tue, 14 Jul 2009 06:30:10 GMT

Today we released MEF Preview 6 on codeplex. Not only is this the feature complete build for MEF V1.0 (which will ship with .NET Framework 4) but it also has the first drop of MEF for Silverlight!

Nick has the best summary of what is new.. but a few highlights:

Silverlight support

Lazy<T> replaces Export<T>

Collection import changes

Inheritance changes

Export attribute is unsealed

Stable Composition makes its debut

Please go download the bits (and full source) which works with .NET Framework 3.5 and Silverlight 3 on the CodePlex site.

As always, we’d love your feedback and thoughts on MEF discussion forum.

Want to know more about MEF? Check out Jason Olson’s new Video

10-4 Episode 26: Creating Extensible Applications with the Managed Extensibility Framework

The DZone interviews Hamilton Verissimo on MEF

BradA — Wed, 13 May 2009 06:24:59 GMT

The DZone has a nice interview with Hamilton on MEF.

Microsoft MEF Q&A with Hamilton Verissimo de Oliveira

Hamilton is one of our PMs here at Microsoft as well as the creator of the very popular Castle Project and he will tell you what the core value of MEF, tell you if MEF a DI container or not and get you versed in the MEF terminology.

Read and Enjoy!

Redmond Developer: Working with MEF in VB and WPF

BradA — Thu, 02 Apr 2009 20:21:00 GMT

Kathleen Dollard has a very good article on that talks about using Managed Extensibility Framework (MEF) to allow customers to add their own forms to our Windows Presentation Foundation (WPF) app?

In this simple example she show adding custom defined forms into the standard menus.. all of this is done in VB!

Redmond Developer: Working with MEF

<Export(GetType(IExtension))> _
<ExportMetadata("MenuCaption", "First")> _
Partial Public Class First
   Implements IExtension

   Public Sub ShowWindow() _
      Implements Common.IExtension.ShowWindow
   End Sub
End Class

Enjoy!

dnrTV Does MEF!

BradA — Mon, 01 Dec 2008 07:56:28 GMT

Glenn Block recently did a great screen cast on the Managed Extensibility Framework.

Show #130 | 11/26/2008

Glenn Block on MEF, the Managed Extensibility Framework
Glenn Block shows you how to use MEF to allow a plugin architecture in your .NET applications. The framework is extensible enough to allow any type to be imported and exported as managed plugins, which are called parts.

MEF Preview 3 Shipped!

BradA — Wed, 26 Nov 2008 07:55:18 GMT

I am pretty excited to see MEF preview 3 ship on codeplex today! Please check out Glenn's post for all the details... This is a release where we really focused on getting in your feedback... We are 100% MSPL, we are shipping our own unit tests, we have made several design changes based on feedback around defaults, ExportProvider, etc. One thing I love about taking on a big customer such as Visual Studio, is you get good, real world feedback up front. In this CTP, we really focused on performance and performance best practices. Whether you use MEF directly or just use Visual Studio, you will appreciate this work!

So grab the bits and let us know what you think!

Managed Extensibility Framework (MEF) Demo

BradA — Sat, 08 Nov 2008 06:10:19 GMT

The Managed Extensibility Framework (MEF) is a new feature of .NET 4 (and will work on 3.5 as well) that makes it significantly easier to extend applications and generally support application composition patterns.

What does that really mean? Well, take 6 mins and 5 seconds to watch this excellent demo Scott Guthrie did at his PDC2008 keynote.

Download video directly

Other MEF resources:

MEF Codeplex site (get the installer and all the source code)
Simple MEF Example
Introduction to MEF
MEF talk at PDC 2008

Repeat of the MEF talk at PDC2008

BradA — Wed, 29 Oct 2008 20:14:56 GMT

After the amazing great reception MEF got during ScottGu's keynote yesterday we had tons of people ask about a MEF session. So we are VERY happy to be able to repeat Glenn's MEF session... Please come if you can.

TL33-R Managed Extensibility Framework: Overview [REPEAT]

Wed 10/29 | 4:45 PM-6:00 PM | 409A
Presenter: Glenn Block
Glenn Block

Please Note: This session is a repeat of TL33, which originally took place on October 27th at 1:45PM. The Managed Extensibility Framework (MEF) is a new extensibility model in the .NET framework that provides a simple declarative model for application developers and extenders to build openly extensible applications. Come to this session and you'll learn about our Composition model and the APIs that work with it. You'll learn about composable parts, exports, imports and the composition container that brings them all together. You'll see how using the model you can develop open-ended applications that can easily be extended both internally and by third-parties.

Simple Introduction to Extensible Applications with the Managed Extensions Framework

BradA — Mon, 29 Sep 2008 18:21:00 GMT

Recently my team has been working on the Managed Extensions Framework (MEF)... I have gotten a chance to explain the concept to folks and I think I have discovered a way to talk about MEF that folks can easily get. So I thought I'd spend a little time walking through a *very* simple MEF example as a way to introduce folks to the power of extensible applications in general, and MEF in particular.

BTW, you can download the current MEF CTP and the final working sample.

Background

Let's start with the most simple example: Hello World!

   1: using System;

2:

   3: class Program

   4: {

   5:     public void Run()

   6:     {

   7:         Console.WriteLine("Hello World!");

   8:         Console.ReadKey();

   9:     }

  10:     static void Main(string[] args)

  11:     {

  12:         Program p = new Program();

  13:         p.Run();

  14:     }

  15: }

Now, you might now always want to print the same string, so let's refactor slightly to pull the string out..

   1: public string Message { get; set; }

2:

   3: public void Run()

   4: {

   5:     Console.WriteLine(Message);

   6:     Console.ReadKey();

   7: }

This looks nice, now we need to add the message... well, the actual text is a separate concern, as such it should be in a different class. Such as:

   1: public class SimpleHello

   2: {

   3:     public string Message

   4:     {

   5:         get

   6:         {

   7:             return "hello world!!";

   8:         }

   9:     }

  10: }

Now we simply need wire these up:

   1: public void Run()

   2: {

   3:     SimpleHello hello = new SimpleHello();

   4:     Message = hello.Message;

5:

   6:     Console.WriteLine(Message);

   7:     Console.ReadKey();

   8: }

This works, but something looks odd about line 3 and 4... We have introduced tight coupling back.. What we really want to do is externalize lines 3 and 4, so they can be controlled without effecting the rest of the logic of the program.

Enter MEF

Add a Reference to the System.ComponentModel.Composition.dll assembly found in the bin directory of the MEF zip.

Add

   1: using System.ComponentModel.Composition;

Now in the Program class, we need to import a value for Message -- that is, we want to specify that someone outside of this program needs to supply a message. Then we need to remove our tight coupling. Note in line 4-5 and we saying we want to import the value for Message. Here I am showing doing it by type (string).. because basic types such as strings might be pretty common, consider using a named import such as [Import("Message")]

   1: class Program

   2: {

3:

   4:     [Import]

   5:     public string Message { get; set; }

6:

   7:     public void Run()

   8:     {

   9:        // SimpleHello hello = new SimpleHello();

  10:         //Message = hello.Message;

11:

  12:         Console.WriteLine(Message);

  13:         Console.ReadKey();

  14:     }

Now in the SimpleHello class we need to export the Message property. This tells the system it can be used to satisfy requirements. Notice line 3 and 4 and am marking it with an Export attribute.. Again, this exports it by type (string in this case). As with above, you might want to do it with an explicit name for a more real world example [Export("Message")]

   1: public class SimpleHello

   2: {

   3:     [Export]

   4:     public string Message

   5:     {

   6:         get

   7:         {

   8:             return "hello world!!";

   9:         }

  10:     }

  11: }

Now we need to tell MEF to wire these up for us.

   1: public void Run()

   2: {

   3:     //SimpleHello hello = new SimpleHello();

   4:     //Message = hello.Message;

   5:     var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

   6:     var container = new CompositionContainer(catalog.CreateResolver());

   7:     container.AddPart(this);

   8:     container.Compose();

9:

10:

  11:     Console.WriteLine(Message);

  12:     Console.ReadKey();

  13: }

In line 5, we create a catalog -- that tells MEF where to look for imports and exports. In this case, we are saying the currently running assembly. There are tons of different parts catalogs, we will look at some later and you can of course build your own.

in line 6, we create a Composition container-- this is effectively the soup that all the different parts will be wired up together.

In line 7, we add this instance of Program to the container so that its dependencies get wired up.

In line 8, we do the compose magic. this is where the Message property of Program gets set.

Notice, in this case the wire up is done by matching types (String to String)... clearly that isn't always the right way, we will look at other ways to wire up later.

Run it and you get the expected output of "hello world!".

Now let's add another message, just to be a little more fun...

   1: public class MoreMessages

   2: {

   3:     [Export]

   4:     public string FunMessage

   5:     {

   6:         get

   7:         {

   8:             return "This is getting fun!";

   9:         }

  10:     }

  11: }

Now run.. It blows up! Why? Well, let's look at the exception:

System.ComponentModel.Composition.CompositionException Error : Multiple exports were found that match the constraint '(composableItem.ContractName = \"System.String\")'. The import for this contract requires a single export only."

From the error it looks like we provided too many ways to satisfy the Import... MEF didn't know which one to pick. Of course you can programmatically get in there and help, you can also just remove the export from one of the messages... but more fun, you can actually tell MEF you are able to deal with zero or more results. Change the Message property of Program as follows:

   1: [Import]

   2: public IEnumerable<string> Messages { get; set; }

Notice we changed the return type to be a collection of strings rather than just one string.

Now change the usage code slightly and we get:

   1: class Program

   2: {

3:

   4:     [Import]

   5:     public IEnumerable<string> Messages { get; set; }

6:

   7:     public void Run()

   8:     {

   9:         //SimpleHello hello = new SimpleHello();

  10:         //Message = hello.Message;

  11:         var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

  12:         var container = new CompositionContainer(catalog.CreateResolver());

  13:         container.AddPart(this);

  14:         container.Compose();

15:

  16:         foreach (var s in Messages)

  17:         {

  18:             Console.WriteLine(s);

  19:         }

20:

21:

  22:         Console.ReadKey();

  23:     }

Wow -- we get both messages! Pretty cool...

More Value of MEF

Ok, I think we can all agree that we added a little complexity if all we were going to do is factor what was in the same assembly. MEF really shines when you have separate independent groups working on different components. By definition these are often in different assemblies with cross no dependencies. To show how MEF supports this, let's add a new Class Library project to our solution. Call it ExternalMessages and add a reference to the System.ComponentModel.Composition.dll assembly.

Add the following class.

   1: using System;

   2: using System.ComponentModel.Composition;

3:

   4: public class Class1

   5: {

   6:     [Export]

   7:     public string Message

   8:     {

   9:         get

  10:         {

  11:             return "I am starting to get it...";

  12:         }

  13:     }

  14: }

Now we need to wire up this class into the catalog... Notice in line 6, we change the catalog to look in a directory for the parts...

   1: public void Run()

   2:  {

   3:      //SimpleHello hello = new SimpleHello();

   4:      //Message = hello.Message;

   5:      var catalog = new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug");

   6:          // new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

   7:      var container = new CompositionContainer(catalog.CreateResolver());

   8:      container.AddPart(this);

   9:      container.Compose();

10:

  11:      foreach (var s in Messages)

  12:      {

  13:          Console.WriteLine(s);

  14:      }

15:

16:

  17:      Console.ReadKey();

  18:  }

Note: DirectoryPartCatalog also supports relative paths that will look for a path under the current AppDomain.CurrentDomain.BaseDirectory. For example:
new DirectoryPartCatalog(@”.\extensions\”);

Run it and we get our new message!

Cool, but we lost our old messages, and I kind of liked them too... Well, luckily, we have an aggregate part catalog that can take parts from several sources.

   1: public void Run()

   2:  {

   3:      //SimpleHello hello = new SimpleHello();

   4:      //Message = hello.Message;

   5:      var catalog = new AggregatingComposablePartCatalog();

   6:         catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

   7:         catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

   8:      var container = new CompositionContainer(catalog.CreateResolver());

   9:      container.AddPart(this);

  10:      container.Compose();

Pretty cool, we now get all the messages!

Finally, just to bring up the point here... I created a bunch of different assemblies that exported Messages... All I need to do is point the catalog at them and go.

   1: public void Run()

   2: {

   3:     //SimpleHello hello = new SimpleHello();

   4:     //Message = hello.Message;

   5:     var catalog = new AggregatingComposablePartCatalog();

   6:        catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

   7:        catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

   8:        catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

   9:     var container = new CompositionContainer(catalog.CreateResolver());

  10:     container.AddPart(this);

  11:     container.Compose();

12:

See where I added them in line 7.. Now just copy the assemblies into this directory and they become available for this program to use! Notice how I don't need to change any of the logic of the core program as I add more and more extensions.

Taking MEF to the Next Level

Above I showed the simplest scenario... let's get a bit more powerful. If you pick apart the main program looking for tight coupling, that Console.WriteLine() will really stand out.. What if you want to log to a file, call a web service or print to HTML or WPF? Tightly coupling to the Console does not make that easy. How can we use the seperation of concerns principle and MEF to get rid of this tight coupling?

First, we need to define an interface that describes the contract for outputting strings. To ensure correct dependency management go ahead and create a new Library project called SharedLibrary, add this interface and reference this project from each of the other team projects.

   1: namespace SharedLibrary

   2: {

   3:     public interface IOutputString

   4:     {

   5:         void OutputStringToConsole(string value);

   6:     }

   7: }

Now, back in the main program we can factor out the Console.WriteLine ()...

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IOutputString Out { get; set; }

8:

   9:     public void Run()

  10:     {

  11:         //SimpleHello hello = new SimpleHello();

  12:         //Message = hello.Message;

  13:         var catalog = new AggregatingComposablePartCatalog();

  14:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  15:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  16:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  17:         var container = new CompositionContainer(catalog.CreateResolver());

  18:         container.AddPart(this);

  19:         container.Compose();

20:

  21:         foreach (var s in Messages)

  22:         {

  23:             Out.OutputString(s);

  24:         }

25:

26:

  27:         Console.ReadKey();

  28:     }

In line 6-7 we define Out and in line 23 we change from Console.WriteLine() to Out.OutputString().

Now in External Messages project add the following class

   1: [Export(typeof(IOutputString))]

   2: public class Class1 : IOutputString

   3: {

   4:     public void OutputString(string value)

   5:     {

   6:         Console.WriteLine("Output=" + value);

   7:     }

8:

9:

Notice here we are explicitly saying the expert type to be that shared interface. Now when we run it we get:

To make things more interesting, lets add another implementation of IOutputString that is a bit more creative.

   1: [Export(typeof(IOutputString))]

   2: public class ReverseOutputter : IOutputString

   3: {

4:

   5:     public void OutputString(string value)

   6:     {

   7:         foreach (var s in value.Split().Reverse())

   8:         {

   9:             Console.ForegroundColor = (ConsoleColor)(s.Length % 10);

  10:             Console.Write(s + " ");

  11:         }

  12:         Console.WriteLine();

  13:     }

  14: }

Just running this now would give us an error right, because we told MEF we wanted exactly one IOutputString... if we change our code to work with multiple we get more fun! In line 7 we changed to request a set of IOutputStrings and in line 19 we changed to loop through all the output devices.

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IEnumerable<IOutputString> OutputSet { get; set; }

8:

   9:     public void Run()

  10:     {

  11:         var catalog = new AggregatingComposablePartCatalog();

  12:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  13:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  14:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  15:         var container = new CompositionContainer(catalog.CreateResolver());

  16:         container.AddPart(this);

  17:         container.Compose();

18:

  19:         foreach (var Out in OutputSet)

  20:         {

  21:             foreach (var s in Messages)

  22:             {

  23:                 Out.OutputString(s);

  24:             }

  25:         }

26:

27:

  28:         Console.ReadKey();

  29:     }

Now when we run it we get all our messages in all our outputs..

Now the only real logic in our main is the nested foreach loops. We may very well like to change that in the future as well... so let's see if we can abstract that out using exactly the same techniques we have talked about already.

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IEnumerable<IOutputString> OutputSet { get; set; }

8:

   9:     [Import("OutputMessages")]

  10:     public Action<IEnumerable<IOutputString>, IEnumerable<string>> OutputMessages { get; set; }

11:

  12:     public void Run()

  13:     {

  14:         var catalog = new AggregatingComposablePartCatalog();

  15:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  16:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  17:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  18:         var container = new CompositionContainer(catalog.CreateResolver());

  19:         container.AddPart(this);

  20:         container.Compose();

21:

22:

  23:         OutputMessages(OutputSet, Messages);

24:

  25:     }

First, in line 9-10 we define an Action that can do the output... and in line 23 we remove our nested foreach loops and replace it with a call to this method. Now all we have in our Main is effectively wiring up components. Very loosely coupled!

Now let's add an option for how the messages are outputted. It would be very easy to define a config file option for selecting these and returning the correct one. Notice that MEF knows that this method follows the contract of the Action delegate above, so it does all the wireup for us.

   1: [Export("OutputMessages")]

   2: public void OutputByMessage(IEnumerable<IOutputString> outputSet, IEnumerable<string> messages)

   3: {

   4:     foreach (var s in messages)

   5:     {

   6:         foreach (var Out in outputSet)

   7:         {

   8:             Out.OutputString(s);

   9:         }

  10:     }

  11:     Console.ReadKey();

  12: }

I would love to hear what you think? Can you think of usage for MEF in your applications? I'd also love for you to grab the final sample and see how many different ways you can extend it.. Here is the final working sample. Enjoy!

PodCast: Glenn Block on Prism, Unity, and MEF

BradA — Wed, 06 Aug 2008 08:10:27 GMT

HerdingCode has recently posted a PodCast with Glenn Block where he talks about Prism, Unity and, of course MEF!

Episode 11: Glenn Block on Prism, Unity, and MEF (part 1)

You gotta love the fast forwards in here.. I wish I had those in my meetings, of course i would never fast forward Glenn ;-)

Managed Extensibility Framework

BradA — Mon, 28 Apr 2008 16:14:40 GMT

Krzysztof recently announced on his blog that we have begun working on an extensibility framework for .NET..

We will blog more details about MEF in the upcoming months, but here are some early details (subject to changes, of course): MEF is a set of features referred in the academic community and in the industry as a Naming and Activation Service (returns an object given a “name”), Dependency Injection (DI) framework, and a Structural Type System (duck typing). These technologies (and other like System.AddIn) together are intended to enable the world of what we call Open and Dynamic Applications, i.e. make it easier and cheaper to build extensible applications and extensions.

[....]

And finally here is some code showing basic scenarios our framework supports:

Creating an Extension Point in an Application:
public class HelloWorld {

  [Import] // import declares what a component needs
  public OutputDevice Output;

  public void SayIt() {
        Output.WriteLine("Hello World");
  }
}
// Extension 
public abstract class OutputDevice {
  void WriteLine(string output){}
}
1. Creating an Extension
[Export(typeof(OutputDevice))] // export declared what a component gives
public class CustomOutput : OutputDevice {
  public void WriteLine(string output) {
    Console.WriteLine(output);
  }
}

 
2. Magic that makes composes (DIs) the application with the extensions.
var domain = new ComponentDomain();
var hello = new HelloWorld();
// of course this can be implicit
domain.AddComponent(hello); 
domain.AddComponent(new CustomOutput());
 
domain.Bind(); // bind matches the needs to gives
hello.SayIt();

We'd love to hear what you think.. please join the discussion on Kry's blog.