My Technobabble : MEF

Bringing MEF and REST love to the UK and at FEST 10

Glenn Block MSFT — Sun, 11 Jul 2010 02:18:56 GMT

Next week I’m coming to the UK where I’ll be spreading the MEF love at FEST 10 and in events in a few other cities. I’ll also be talking about REST and the new work we are doing in WCF to provide a better experience for building RESTful systems.

Below is the event schedule

Date/Time	Event	Location	Talk(s)
14 July 2010 10:00 AM to 2:00 PM	Microsoft UK	Microsoft Campus Reading	.NET Managed Extensibility Framework with Glenn Block [A half day of MEF] The Managed Extensibility Framework (MEF) is a new library which is part of the .Net 4.0 framework. MEF helps you build extensible and maintainable applications, which you can evolve over time, by providing a mechanism that promotes decoupling and separation of concerns, and supports plugins. Come join us on this quest for enlightenment in the way of MEF. We will start our journey light with the essentials of composition in MEF: Import, Export and Compose. We will then travel together on the path as we elevate toward master.
14 July 2010 7:00 PM to 9:00 PM	NxtGenUG	Microsoft Research Cambridge	Silverlight Application Partitioning and Extensibility with MEF Wouldn't it be nice if your team could add new features to your applications without all the headache they have to deal with today? With the Managed Extensiblity Framework (MEF) in 4.0 you can bolt your apps together dynamically on the fly. Adding new modules and features is as simple as deploying a new binary, you don't have to touch the existing code. You can even deploy those features as separate XAP files which can be loaded on-demand! Come to this talk for a quick tour of what MEF is, and learn how you can use it to beat out your competition.
15 July 2010 Evening	Geek Dinner	Somewhere in London near Victoria	Register here quick: http://is.gd/dolgi
16 July 2010	Fest 2010!	Bournemouth Pier Bournemouth	Building extensible frameworks with MEF Come to this talk where we will take a deep dive into building frameworks which can easily extended by third-parties. For the first part of the session we will learn about what MEF offers for framework authors as we build a small extensible library which leverages it. Then in the second part we’ll dive into several OSS frameworks that are utilizing MEF for extensibility. We’ll also leave plenty of time to answer any deep questions you have on MEF. REST, It’s more than Data Today it’s very common to simply throw some data over the wire and call it REST. But REST as Roy Fielding described it is much, much more. Come to this session and we’ll explore the tenants of a RESTful system. We’ll start with looking at traditional web services, then we’ll remove the SOAP shackles and explore what we can achieve as we get closer and closer to HTTP. We’ll also look at various frameworks both within and outside Microsoft for achieving REST Nirvana.

All of this is made possible by the fine folks at NxtGenUG who have been gracious to sponsor my trip.

I look forward to seeing all of you on the other side of the Atlantic!!!

Open sourced .NET libraries in Mono

Glenn Block MSFT — Thu, 08 Jul 2010 08:46:09 GMT

Recently Miguel did a post that made me smile. He talked about several libraries from Microsoft which were released under an OSS license and thus incorporated into the Mono tree and ship as part of Mono 2.8. I smiled for two reasons. One, I was happy to see that Microsoft is becoming more and more open with our development platform. Second, I was happy because MEF was on that list. :-)

The full list is below:

Managed Extensibility Framework, a framework to create extensible applications (blogged about their open sourcing).
The Dynamic Language Runtime is the engine that powers IronPython and IronRuby, but also third party efforts like IronJS and RemObject's Javascript compiler. This lives largely in the System.Core assembly in .NET 4. Some of the code is also used in Mono's version of System.Numerics.
OData's .NET client (System.Data.Services.Client), I blogged about this here.
ASP.NET MVC both MVC1 and MVC2.
Microsoft's AJAX library for use with ASP.NET WebForms.
Silverlight's Controls, these are used by Moonlight.

I hope this is just the beginning!

Way of MEF slides and Code

Glenn Block MSFT — Sun, 13 Jun 2010 07:11:52 GMT

Thanks to everyone who came out to the “Way of MEF” education day in Cupertino. I had a great time and you were an awesome audience. I really appreciate all the great / in-depth questions. It showed that you really were keeping along. I also enjoyed all the different side conversations, and all the times you guys overwhelmed me at the breaks. I really do love this stuff!

Here is a link to get you access to the code and the slides: http://cid-f8b2fd72406fb218.office.live.com/browse.aspx/Public/Way%20of%20MEF

If you download the code it contains the following:

HelloMef_Simple - The simple widget example we built
HelloMef_Extended - Sample that downloads multiple XAPs and which demonstrates ExportFactory.
MefRules_Simple - The simple rules engine we built on the fly
MefRules_Extended - More complete rules engine sample which uses rule metadata and contains a runner for Silverlight and Desktop.
DynamicObjectContracts - Demonstrates a simple illustration of using dynamic exports and imports
PartUpdatesInPlace - Demonstrates uses shadow copying to allow hot swapping / removing parts on the fly. (the one that the audience asked me about)

Here are additional links:

Default exports: http://blogs.msdn.com/b/gblock/archive/2009/05/14/customizing-container-behavior-part-2-of-n-defaults.aspx
Filtered Catalogs: http://mef.codeplex.com/wikipage?title=Filtering%20Catalogs&referringTitle=Guide
Config export provider: http://codepaste.net/en44vo
Ruby and MEF: http://blogs.msdn.com/b/nblumhardt/archive/tags/ruby/
ASP.NET MVC and MEF: MEF and ASP.NET MVC sample updated
ASP.NET Web Forms and MEF (doesn’t use CompositionInitializer approach): WebForms and MEF Sample
Diagnosing MEF - http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line.aspx

Finally as promised, if you have questions that were not answered in the talk, feel free to comment here or email me direct and I will answer them in a follow up post.

Thanks to Mathias Brandewinder, Kevin Rohling, his nutty girlfriend and recruiter extraordinaire Megan Hopkins and the Bay.NET UG for hosting me. I had an awesome time.

Yes, I know I need to post on what I am working on now……I hear you, pleae be patient :-)

MEF day in SF, “The Way of MEF, the Path to Enlightenment”

Glenn Block MSFT — Thu, 03 Jun 2010 08:08:12 GMT

On Saturday June 12th I am stoked to be coming to the SF bay area on behalf of the Bay.Net UG where I’ll be delivering a full day on MEF!

We’re going to cover a world of topics as you can see from the list below.

1. How to lazily instantiate parts to conserve processor cycles
2. Self-describing parts in order to allow more flexible discovery
3. Diagnosing common MEF failures
4. Adapting legacy components to work with MEF
5. Partitioning your Silverlight applications across multiple XAPs to reduce download cost and improve startup time
6. Providing default overridable parts
7. Using hierarchical containers for scoped composition
8. Creating custom catalogs to apply custom policy for filtering
9. Creating export providers to integrate with existing service providers
10. Composing UIs with MEF / MEF with Prism
11. Implementing MVVM with MEF

The cost is $39. Register here while there is still time!

MEF has shipped!!!

Glenn Block MSFT — Thu, 03 Jun 2010 01:26:00 GMT

You might have missed it, but a few weeks ago MEF V1 shipped in .NET 4.0 and Silverlight 4! As a team we’re really happy to have seen MEF hit the wild. We believe MEF helps you to build better applications that are easier to extend. To get started with MEF, go visit our wiki here

So far we’ve been hearing lots of goodness from customers that they feel the same. We’ve also been really happy seeing a healthy set of projects in the open source community pulling in MEF to address their extensibility challenges within their frameworks and applications. We’ve also had some interesting ports of MEF which is a great outcome of having an OSS license!

Below is a list of some of the folks internal and external to Microsoft that are using MEF along with the scenarios for which they use/support us (in a completely random order)

Visual Studio 2010	New extensible editor Project system uses MEF under the covers VS Ultimate uses MEF for it’s UML designers Several other teams like EF use MEF for their designers
MEF Contrib	Community driven extensions to MEF
Silverlight Analytics Framework	Allows plugging in different analytic engines through MEF
Silverlight Media Framework	Uses MEF for plugging in various extensions relating to the player
TypeMock Test Lint	Uses MEF for allowing you to plug in your own custom rules
RavenDB	Uses MEF to allow plugging in triggers
Caliburn	Supports plugging in MEF as a service provider
Common Service Locator	Provides an adapter for working with MEF
MefedMVVM	MEF handles discovery and wire up of View Models both at runtime and design time
PHPMEF	Yes, it’s possible, MEF for PHP :-)
PocketMEF	MEF for PocketPC
Mono	Yes you heard it right, MEF 3.5 joins MVC2, System.Dynamic and OData client as part of the mono.

MEF V1 has been an awesome ride. The best part has been the fantastic community that worked with us every step of the way giving us continual feedback and ensuring our success as well as our internal partners who pressed hard on us to keep us honest. Thank you for all your help and support!

I also want to thank my team for the fantastic work they did. It was an amazing experience building MEF together!

Sit tight, MEF v2 is on the way!

Caveats about DeploymentCatalog

Glenn Block MSFT — Tue, 13 Apr 2010 20:58:00 GMT

The information below was wrapped up in my previous post on DeploymentCatalog. As a bunch of folks have been asking questions on this, it seems worth to rip out on it's own.

A few caveats about DeploymentCatalog.

DeploymentCatalog is a very exciting addition to the MEF box. There are a few caveats to it’s usage.

Does not support Silverlight cached assemblies. (Otherwise known as TPEs). This means that DC will not download referenced assemblies that are packaged with the Silverlight caching infrastructure (.extmap).
- This includes cached assemblies in the main xap.
- If the cached assemblies are referenced by the main app, they will be available to the assemblies in a downloaded XAP.
- You can create shared xaps which contain assemblies to be used by other xaps and download those with the DeploymentCatalog. As long as the shared xaps are downloaded first they will be available to others.
- If you do decide to use either of the previous approaches, be sure to set your references to “Copy Local = False” in your XAPs otherwise you will be embedding the shared assemblies again.Does not support localization.
- We are looking into cached assembly support in the future.
Does not support non-embedded resources.
Local resource references in XAML also are not supported i.e. using pack URIs. You can programatically access embedded resources though.

View Model Locator – MEF Style

Glenn Block MSFT — Tue, 30 Mar 2010 09:19:07 GMT

At MIX, Laurent Bugnion and I had a brainstorming chat around improving on the ViewModel locator “pattern” through the usage of a MEF generic locator that allows binding via indexer properties thus removing the need for a hard-coded locator. Tonite John Papa pinged me with a similar thought. Next thing you know we paired up for about 40 mins…and Voila, Success!

Caveat: We hit a binding bug on SL4 that made it a little uglier than it needs to be through requiring a converter. Hopefully that will be fixed soon.

Go read about it on John’s blog!

Hamilton and I MEFFing it up on Silverlight TV

Glenn Block MSFT — Sun, 14 Mar 2010 14:01:23 GMT

Several weeks ago Hamilton and I recorded several episodes with John Papa on the new Silverlight TV show on Channel 9. We did not one or two but FOUR episodes on Silverlight TV covering the basics as well as some more advanced cases like using metadata views and application partitioning. We also discussed when you should and should not use MEF.

Silverlight TV Episode 4: 3 Steps to MEF - Export, Import, Compose

Silverlight TV Episode 5: Using Metadata with MEF

Silverlight TV 7: When and Where to use MEF

Silverlight TV 11: Dynamically Loading XAPs with MEF

It was great hanging out with John and exploring what you can do with this technology. Also, he’s an awesome host :-)

If you want to get quickly ramped up on what MEF is and how you use it in Silverlight, go check them out!

Speaking at MIX!

Glenn Block MSFT — Thu, 11 Mar 2010 10:18:00 GMT

Sunday I leave to Vegas to attend my first MIX. It’s exciting to finally attend this event that has such an air of mystique around it. I’ll be speaking on how you can use MEF in SL4 to partition your applications across many XAPs in a fairly seemless fashion. My talk is short, but it’s going to be very focused. If you’ve heard of MEF but are not sure what to do with it, or you know MEF and want to see some new ways it can help you make your Silverlight apps offer a better user experience, come to this talk.

Microsoft Silverlight Optimization and Extensibility with MEF

Glenn Block in Lagoon B on Tuesday at 3:35 PM

Wouldn't it be nice if your team could add new features to your applications without all the headache they have to deal with today? With the Managed Extensiblity Framework (MEF) in 4.0 you can bolt your apps together dynamically on the fly. Adding new modules and features is as simple as deploying a new binary, you don't have to touch the existing code. You can even deploy those features as separate XAP files which can be loaded on-demand! Come to this talk for a quick tour of what MEF is, and learn how you can use it to beat out your competition.

Speaking on “Ignite your coding”

Glenn Block MSFT — Mon, 08 Mar 2010 22:39:23 GMT

This Thursday, I’ll be joining John Bristowe and Joey Devilla to talk about composite applications, patterns, MEF and anything else that comes up. I am flexible :-)

This is a live webcast where questions will be taken in real time, so ask away! I am selfish but no slides or demo prep sounds great to me!

Building HelloMEF – Part V – Refactoring to ViewModel

Glenn Block MSFT — Mon, 08 Mar 2010 09:22:58 GMT

In the last post we migrated over to the new DeploymentCatalog. In this post we’ll look at refactoring the code to incorporate the MVVM pattern. Code from the last post is available here

Why ViewModel?

There’s a ton of content out there in the blogosphere that discuss the virtues of separated presentation patterns including MVVM. I am not going to reiterate those here, but I will point you at Josh Smith’s excellent MVVM article here. I’ll also shamelessly plug my own post where I shared my own view on the essence of MVVM (which is based on views of others i respect). In short it’s about decoupling UI logic for better maintainability which includes making it easier for a graphic designer to style the UI.

So where are the maintainability issues in the current “app”? Currently the main place is within MainPage.xaml.cs where you see the following code:

public void OnImportsSatisfied()

{

    TopWidgets.Items.Clear();

    BottomWidgets.Items.Clear();


    foreach (var widget in Widgets)

    {

        if (widget.Metadata.Location == WidgetLocation.Top)

            TopWidgets.Items.Add(widget.Value);

        else if (widget.Metadata.Location == WidgetLocation.Bottom)

            BottomWidgets.Items.Add(widget.Value);

    }

}

The logic is simple yes, but it still has issues.

The main issue is that it is mixing UI business logic with the rendering. The logic which determines which item goes to Top to Bottom is a completely separate concern from how those items actually get displayed. Having the logic mixed in means the code is very brittle where any slight change to the way the UI is rendered can break it. It also makes it difficult for a graphic designer from being able to change the look and feel of how the widgets are rendered.
The second issue is that I am imperatively adding elements to the UI rather than letting the rich DataBinding engine do the work it was designed for. This makes it difficult to re-skin the UI.
Third, in it’s current form, the logic is difficult to test, meaning if the logic breaks I am relying on QA / manual testing to pick it up.

So ViewModel will fix all of this?

I say with confidence Yes! Using ViewModel will allow us to refactor the logic into a nice reusable and testable place. It will also gives us the decoupling we need to leverage the Silverlight rendering engine to it’s fullest. Along the way you will also see how MEF can help us with regards to implementing MVVM within our applications. We’ll introduce 2 view models to help us get there. When we’re done, our application will look like this.

Pre-requisites.

As with the last post, you’ll need our MEF codeplex bits for following along. If you start where we left off in the last post you’ll be fine. You’ll also need a copy of Laurent Bugnion’s awesome “Glenn Block approved” :-) MVVM Light, which you can get here and which we’ll be using for it’s ICommand default implementation.

Let the refactoring begin!

First we’ll go create our ViewModel. We’ll start off with an empty class. Go add a new MainPageViewModel.cs class to the HelloMEF project. Leave it empty for now. Now let’s refactor MainPage to have MEF deliver it’s ViewModel. There’s a lot of religous debate in the community around View First vs ViewModel First construction of the UI. I am going to use View first, period, and no that’s not open for debate :-)

Refactoring MainPageView

What we’re going to do is rip out the logic in MainPageView, and replace it with importing it’s ViewModel and setting it to the DataContext. Replace MainPageView.xaml.cs the following:

public partial class MainPage : UserControl

{

    public MainPage()

    {

        InitializeComponent();

        CompositionInitializer.SatisfyImports(this);

        this.DataContext = ViewModel;

    }


    [Import]

    public MainPageViewModel ViewModel { get; set; }

}

I think you’ll agree this code is a lot cleaner. My UI is now completely decoupled from any UI “logic”.

But WAIT, there IS code in the code behind, and the ViewModel police are probably on their way to my house. My answer when they show up is “it’s simple wiring logic, so WHAT!” That being said you can certainly look at ways to remove to right that small amount of code, but I am not losing any sleep over it. :-)

Notice I am not using constructor injection rather I am importing my ViewModel through a property. The reason is because I am allowing XAML to create my view rather than having MEF create it for me. SatisfyImports is then called to tell MEF to inject the view. It removes one level of mental gymnastics which in particular manifests itself when you start dealing with nested Views and ViewModels. If you’ve dealt with manually assembling Composite UIs / using regions, you know what I mean. It also allows this view to be more designer friendly as I can configure a design time VM to show up. That is for another post.

Fleshing out MainPage’s ViewModel

Now we’re go and finish the empty MainPageViewModel we created earlier. We’re not just going to move the code from the view into the model as we’d just be moving the problem. Instead we’re going to get rid of the imperative code and allow the view to render itself on the model through binding. We’ll still need to leverage MEF’s metadata and ensure that the widgets go in the right “place” wherever that happens to be. This raises a question as to how as previously there was a single collection of widgets that we imported into MainPage before and which we manually walked. The solution I chose was to create collection properties for each set of widgets. That allows the view to render it any way it wishes and decouples from the ItemsControls that were used previously.

Below is the code:

[Export]

public class MainPageViewModel : IPartImportsSatisfiedNotification, 

    INotifyPropertyChanged

{

    [ImportMany(AllowRecomposition = true)]

    public Lazy<UserControl, IWidgetMetadata>[] Widgets { get; set; }


    public IEnumerable<UserControl> TopWidgets { get; private set; }


    public IEnumerable<UserControl> BottomWidgets { get; private set; }


    public void OnImportsSatisfied()

    {

        TopWidgets = Widgets.Where(w => w.Metadata.Location == 

            WidgetLocation.Top).Select(i => i.Value);

        BottomWidgets = Widgets.Where(w => w.Metadata.Location == 

            WidgetLocation.Bottom).Select(i => i.Value);

        OnPropertyChanged("TopWidgets");

        OnPropertyChanged("BottomWidgets");

    }


    public event PropertyChangedEventHandler PropertyChanged;


    private void OnPropertyChanged(string property)

    {

        var handler = PropertyChanged;

        if (handler != null)

            PropertyChanged(this, new PropertyChangedEventArgs(

                property));


    }

}

MainPageViewModel implements IPartImportSatisfiedNotification as the view did previously. It also implements INotifyPropertyChanged in order to tell the view whenever it is recomposed. It exports itself in order to make itself available to be imported by the view. MainPageViewModel imports all the Widgets as did the view, but it also exposes two different properties TopWidgets and BottomWidgets. Whenever recompostion occurs, OnImportsSatisfied is called which updates these properties with their own filtered collections by using a LINQ query with the appropriate metadata filter. It then raises PropertyChanged in order to update the UI. This really shines through the power of metadata and metadata views in MEF!

Updating the bindings

The last thing we need to do to get the ViewModel wired is to update the view to bind the widget ItemControls to the appropriate properties. Replace the StackPanel in MainPage.xaml.

<StackPanel x:Name="LayoutRoot" Background="Black">

    <Border Background="Cyan">

        <ItemsControl x:Name="TopWidgets" 

            ItemsSource="{Binding TopWidgets}" Height="Auto" 

            FontSize="30">

        </ItemsControl>

    </Border>

    <Border Background="Yellow">

        <ItemsControl x:Name="BottomWidgets" 

            ItemsSource="{Binding BottomWidgets}" Height="Auto" 

            FontSize="30">

        </ItemsControl>

    </Border>

</StackPanel>

We’re almost there

Build and execute the app. You should see that everything works as before only now our new ViewModel is in place. You can now easily go and and reformat the UI without impacting the underlying ViewModel at all. We could stop here as we’ve already made a good leap in improving the maintenance of our app. We won’t though, there’s one more culprit we can refactor. Widget1.

What’s wrong with Widget1?

[ExportWidget(Location = WidgetLocation.Top)]

public partial class Widget1 : UserControl

{

    [Import]

    public IDeploymentCatalogService CatalogService { get; set; }


    public Widget1()

    {

        InitializeComponent();

        Button.Click += new RoutedEventHandler(Button_Click);

    }


    void Button_Click(object sender, RoutedEventArgs e)

    {

        CatalogService.AddXap("HelloMEF.Extensions.xap");

    }

}

Widget1 contains logic which calls the DeploymentCatalogService to download a XAP, it’s not horrible but it has some of the same problems as MainPage did.

It tightly couples the download logic to the UI. This means if you refactor the UI there is a decent chance it will break.
- Downloading widgets is a completely non-UI concern which does not belong in the view.
- It means a designer can’t change from using a button without modifying the code.
The logic is not reusable, you can’t reuse it across multiple views. This may or may not matter depending on the specific case.
As small as it is, it is hard to test. That means if someone breaks the code and it no longer works, the only way to pick it up is through QA/automated UI testing. We want to pick up as many bugs as we can up stream rather than waiting for them to be caught.

Refactoring Widget1 to use a ViewModel.

Widget1 can be refactored to use it’s own ViewModel. We can then refactor the logic out of the code behind and move it into the model leveraging Silverlight 4’s new commanding support, Laurent’s MVVM light library, and a little MEF to make it more maintainable.

We’ll do this again with the ViewFirst approach :-) This time we don’t need to use CompositionInitializer though as our ViewModel will get discovered by the catalog. Add a new Widget1ViewModel.cs file to the HelloMEF project. Second add a reference to GalaSoft.MVVM light (in your “ProgramFiles\Laurent Bugnion (Galasoft)\Mvvm Light Toolkit\Binaries\Silverlight” folder). Now paste in the following code to Widget1ViewModel.cs.

using System.ComponentModel.Composition;

using System.Windows.Input;

using GalaSoft.MvvmLight.Command;


namespace HelloMEF

{

    [Export]

    public class Widget1ViewModel

    {

        public Widget1ViewModel()

        {

            Download = new RelayCommand(() => 

                CatalogService.AddXap("HelloMEF.Extensions.xap"));

        }


        [Import]

        public IDeploymentCatalogService CatalogService { get; set; }


        public ICommand Download { get; private set; }

    }

}

Widget1ViewModel is an export similar to MainPageViewModel. It imports IDeploymentCatalogService in order to allow downloading XAPs. It then exposes a Download command which is implemented using MVVM Lights’ (contributed by Josh Smith) RelayCommand to download the extensions.

Updating Widget1View

Once we have that in place we can clean up the Widget1 view. Paste the following into Widget1.xaml.cs.

[ExportWidget(Location=WidgetLocation.Top)]

public partial class Widget1 : UserControl

{

    public Widget1()

    {

        InitializeComponent();

    }


    [Import]

    public Widget1ViewModel ViewModel

    {

        get{ return (Widget1ViewModel) this.DataContext;}

        set { this.DataContext = value;}

    }

}

First I removed the previous UI logic. Then I added an import of the MainPageViewModel and set it to the DataContext. Constructor injection was also an option through usage of our ImportingConstructor attribute. I chose not to for consistency and in order to not increase the concept count. Feel free to use either approach though.

Now that we’ve updated the code behind we can update the XAML to bind to the new DownloadCommand. Replace the Grid element in Widget1.xaml with the following.

<Grid x:Name="LayoutRoot" Height="Auto">

    <Button x:Name="Button" Content="Hello MEF!" 

        Command="{Binding Download}" Width="300" Height="100">

    </Button>

</Grid>

Run the app!

Build and run the application, press the top button and you should see a screen that is quite familiar by now :-)

We’re done.

What did we gain?

You might be sitting there thinking wow that was fun, but what did it buy me? Here’s a quite summary:'

MainPage and Widget1 are completely decoupled from the UI logic.
MainPageViewModel and Widget1ViewModel are easily testable.

Both of which translate into less pain for us as our app evolves.

How did MEF help?

MEF enabled us to put the decoupled pieces back together. To be fair, we could have used other mechanisms. However MEF offered a nice solution in the box, which was convenient as our app was already using it :-) MEF also provided us CompositionInitializer which made it very easy to compose our UI parts without having to jump through a lot of hoops.

What’s next?

In this post I mentioned testing several times though notice I did not show ANY tests. That was deliberate :-) The reason is because I wanted you to see the value of ViewModel beyond the simple testability aspects, I wanted you to focus on how it improved our code whether we were testing it our not. In the next post we’ll look at how we can test it.

As always, code is attached.

Building Hello MEF – Part IV – DeploymentCatalog

Glenn Block MSFT — Mon, 08 Mar 2010 01:54:00 GMT

Continuing on with the series. In part III we introduced the concept of application partitioning through the use of the PackageCatalog which ships in the Silverlight toolkit. In this post we’ll take a look at a new API known as the DeploymentCatalog which ships in the box! We also look at some changes to our hosting APIs. If you are following along, the completed code from that post is available here.

Note: Instead of using the MEF binaries that ship as part of SL4 beta, we’re going to use our newer bits available on Codeplex from this point forward. It is very likely these same APIs will be available in the box when SL4 ships ;-)

DeploymentCatalog

With our latest codeplex drop we introduced a new API called DeploymentCatalog. DeploymentCatalog is basically a redesign of the catalog that we included in the toolkit. As part of the redesign we address some thread-safety issues as well as made the catalog more robust.

DeploymentCatalog (DC) is used for dynamically downloading MEF catalogs in an async fashion. To use it you call the DownloadAsync method passing in a uri with the default overload accepting a relative uri. The uri should point to a XAP which contains MEF parts. Once you initiate the download, DC will start the download. Upon completion DC will rip open the XAP, load all the assemblies within and add any attributed parts to the catalog. You’ll notice that unlike PackageCatalog which holds a collection of packages for multiple XAPs, each DC corresponds to a single XAP.

Below is a snippet of how to use it.

var catalog = new DeploymentCatalog("Extensions.xap");
catalog.DownloadAsync();

Passing deployment catalogs to PartInitializer

In the previous bits, CompositionHost.InitializerContainer was called in order to pass a container configured with a PackageCatalog which PartInitializer could use.In the new bits PartInitializer has been renamed to CompositionInitializer (more on that later). Additionally we’ve renamed InitializeContainer to Initializer and added a new convenience overload which accepts a param array of catalogs. When you use this overload you need to decide if you want the default XAP’s parts to be added. To do this pass in a DeploymentCatalog created with the default constructor such as the example below:

CompositionHost.Initialize(new DeploymentCatalog(), catalog);

Using the catalog from the previous example this will add all of the parts from the current XAP as well as any parts that are discovered in “Extensions.xap”.

Recomposition in DeploymentCatalog

Each DC downloads in an asynchronous manner. Because DC is recomposable (implements INotifyComposablePartCatalogChanged), it will notify whenever the download completes. This means that you are not required to subscribe to the DownloadCompleted event, as because the catalog is recomposable, it will force the container to recompose upon the receipt of parts. In the previous example, adding a catalog to DC does not mean that it’s parts have been downloaded yet. However once those parts are downloaded, the container will recompose.

Tracking completion, errors and progress.

You can, and we recommend you do track download completion and errors. Whenever a download completes, the catalog will raise a “DownloadCompleted” event. If the download fails for some reason, then DownloadCompleted will be fired setting the Error to the download error. You can also track overall progress of the download by subscribing to the DownloadProgressChanged event. Finally if your application logic requires it you can even cancel the download by calling CancelAsync.

For example see the snippet below.

void DownloadCatalog(string uri) {
    var catalog = new DeploymentCatalog(uri);
    catalog.DownloadCompleted += new EventHandler<AsyncCompletedEventArgs>(DownloadCompleted);
    catalog.DownloadProgress += new EventHandler<DownloadProgressChangedEventArgs>(DownloadProgressChanged);
    catalog.DownloadAsync();
    //cancel the catalog download due to a timeout
    catalog.CancelAsync();
}
void DownloadCompleted(object sender, AsyncCompletedEventArgs e)
{
    if (e.Error != null)
         throw e.Error;
}
void catalog_DownloadProgressChanged(object sender, DownloadProgressChangedEventArgs e)
{
  //progress logic here
}

Allowing parts to download XAPs.

In the last post we added the PackageCatalog directly to the container in order to allow parts to import it. A cleaner approach is to encapsulate the catalog management into a nice service that other parts can depend on. This allows the host to have more fine-grained control over how and what enters the container. In the sections that follow you’ll see I’ve introduced a DeploymentCatalogService for this purpose.

Migrating the code

OK, let’s start migrating the code to use the new DeploymentCatalog apis. Again the starter code is available here

Download MEF bits

First we need to go download the latest MEF bits from Codeplex from here. Extract the zip (make sure to unblock all files if you are letting windows extract it for you). Next open the HelloMEF solution in Visual Studio and go and remove all references to SystemComponentModel.Composition.dll, System ComponentModel.Composition.Initialization.dll, and SystemComponentModel.Composition.Packaging.Toolkit.dll from each project.

Fix MEF References

Now go add references to the newer binaries located in the .\bin\SL folder. Here are the projects and references.

HelloMEF –> Add System.ComponentModel.Composition.dll and System.ComponentModel.Composition.Initialization.dll.
HelloMEF.Contracts –> Add System.ComponentModel.Composition.dll.
HelloMEF.Extensions –> Add System.ComponentModel.Composition.dll.

Introducing DeploymentCatalog service.

In order to handle initializing the host as well allowing other parts to download, we’ll create DeploymentCatalogService.

First add a new interface to HelloMEF.Contracts using the following code.

public interface IDeploymentCatalogService
{
    void AddXap(string uri, Action<AsyncCompletedEventArgs> completedAction = null);
    void RemoveXap(string uri);
}

Next add a new DeploymentCatalogService to the HelloMEF project.

[Export(typeof(IDeploymentCatalogService))]
public class DeploymentCatalogService : IDeploymentCatalogService
{
    private static AggregateCatalog _aggregateCatalog;
    Dictionary<string, DeploymentCatalog> _catalogs;
    public DeploymentCatalogService()
    {
        _catalogs = new Dictionary<string, DeploymentCatalog>();
    }
    public static void Initialize()
    {
        _aggregateCatalog = new AggregateCatalog();
        _aggregateCatalog.Catalogs.Add(new DeploymentCatalog());
        CompositionHost.Initialize(_aggregateCatalog);
    }
    public void AddXap(string uri, Action<AsyncCompletedEventArgs> completedAction = null )
    {
        DeploymentCatalog catalog;
        if (!_catalogs.TryGetValue(uri, out catalog))
        {
            catalog = new DeploymentCatalog(uri);
            if (completedAction != null)
                catalog.DownloadCompleted += (s, e) => completedAction(e);
            else
                catalog.DownloadCompleted += new EventHandler<System.ComponentModel.AsyncCompletedEventArgs>(catalog_DownloadCompleted);
            catalog.DownloadAsync();
            _catalogs[uri] = catalog;
        }
        _aggregateCatalog.Catalogs.Add(catalog);
    }
    void catalog_DownloadCompleted(object sender, System.ComponentModel.AsyncCompletedEventArgs e)
    {
        if (e.Error != null)
            throw e.Error;
    }
    public void RemoveXap(string uri)
    {
        DeploymentCatalog catalog;
        if (_catalogs.TryGetValue(uri, out catalog))
        {
            _aggregateCatalog.Catalogs.Remove(catalog);
        }
    }
}

DeploymentCatalogService handles adding / removal of DeploymentCatalogs. It also exposes a static Initialize method which handles setting up the host to allow dynamic download. This method creates an aggregate catalog, and adds the parts in the default XAP to it. It then calls CompositionHost.Initialize to pass that catalog to the host. Once the host has been configured, any catalogs added to the aggregate will then automatically show up in the host.

Note: DeploymentCatalogService is simply a helper, it is NOT required in order to use DeploymentCatalog.

Initializing the host

Now that DeploymentCatalogService is added, go remove the old Initialization code which used PackageCatalog from the App class and have it call Initialize.

private void Application_Startup(object sender, StartupEventArgs e)
{
    DeploymentCatalogService.Initialize();
    this.RootVisual = new MainPage();
}

Refactoring Widget1 to use DeploymentCatalogService

Next go change Widget1.xaml.cs replacing the importing PackageCatalog with IDeploymentCatalogService.

[ExportWidget(Location=WidgetLocation.Top)]
public partial class Widget1 : UserControl
{
    [Import]
    public IDeploymentCatalogService CatalogService { get; set; }
    public Widget1()
    {
        InitializeComponent();
        Button.Click += new RoutedEventHandler(Button_Click);
    }
    void Button_Click(object sender, RoutedEventArgs e)
    {
        CatalogService.AddXap("HelloMEF.Extensions.xap");
    }
}

Build it!

Go build the project and run it. Press the top “Hello MEF” button and you should see a new green part appear which was dynamically downloaded through the new DeploymentCatalog.

A few caveats about DeploymentCatalog.

DeploymentCatalog is a very exciting addition to the MEF box. There are a few caveats to it’s usage.

Does not support Silverlight cached assemblies. (Otherwise known as TPEs). This means that DC will not download referenced assemblies that are packaged with the Silverlight caching infrastructure (.extmap).
- This includes cached assemblies in the main xap.
- If the cached assemblies are referenced by the main app, they will be available to the assemblies in a downloaded XAP.
- You can create shared xaps which contain assemblies to be used by other xaps and download those with the DeploymentCatalog. As long as the shared xaps are downloaded first they will be available to others.
- If you do decide to use either of the previous approaches, be sure to set your references to “Copy Local = False” in your XAPs otherwise you will be embedding the shared assemblies again.Does not support localization.
- We are looking into cached assembly support in the future.
Does not support non-embedded resources.
Local resource references in XAML also are not supported i.e. using pack URIs. You can programatically access embedded resources though.

Summary

Used properly, DeploymentCatalog is a great way to partition your Silverlight applications in order to improve startup time as well as allowing third-parties to extend your Silverlight applications.

Completed code is attached.

Hosting MEF within application and libraries.

Glenn Block MSFT — Mon, 01 Feb 2010 09:51:14 GMT

As you start to work with MEF one of the fundamental decisions you have to make is how MEF will be hosted. There are several factors which will impact your decision including whether you are building on Silverlight or the Desktop and whether you are building an application or a library.

The first concern you hit around MEF is how and where composition starts. MEF parts at the end of the day are simply classes (in our attributed model). Simply adding an Export attribute to a class does not cause it to get composed as something has to start the composition. That responsibility falls on the CompositionContainer. It uses one or more catalogs to discover the available parts in the system. Once the container is created, composition can begin. But it doesn’t begin until the container is asked to do work. This normally happens in the entry point of the application or application root, which in a WPF/Silverlight application would be the Application class.

There are several approaches to composition in MEF.

Composing an existing part

The first approach is to pass an existing instance to MEF and ask it to compose it. The advantage of this approach is that it lets you declare imports on the existing application instance.

[Import]
public Window MainWindow { get; set; }
void App_Startup(object sender, StartupEventArgs e)
{
    var catalog = new AssemblyCatalog(typeof(App).Assembly);
    var container = new CompositionContainer(catalog);
    container.ComposeParts(this);
    base.MainWindow = Window;
    MainWindow.Show();
}

Pulling on the container for an export

In this approach you pull on the container and ask MEF to create a part.

void App_Startup(object sender, StartupEventArgs e)
{
    var catalog = new AssemblyCatalog(typeof (App).Assembly);
    var container = new CompositionContainer(catalog);
    this.MainWindow = container.GetExportedValue<Window>();
    MainWindow.Show();
}

In the startup method above I am creating a catalog with the current assembly, adding it to a container and then querying for the MainWindow. During the querying, MEF discovers the MainWindow (assuming it was exported)

Creating a standardized class for starting composition

In the previous examples, bootstrapping code is introduced into the startup of the application. This kind of approach works well for client / server applications that have a centralized initialization point. In the previous case the initialization code is very specific. With some refactoring I can create a standardized initialization mechanism such as CompositionStarter below which can be reused across different UI mediums including on the server.

public class CompositionStarter<TParams>
{
    private CompositionContainer _container;
    public CompositionStarter(params ComposablePartCatalog[] catalogs)
    {
        var aggregate = new AggregateCatalog(catalogs);
        _container = new CompositionContainer(aggregate);
    }
    
    public CompositionStarter(CompositionContainer container)
    {
        if (container == null)
            throw new ArgumentNullException("container");
        _container = container;
    }
    public CompositionStarter()
    {
        _container = new CompositionContainer(new AssemblyCatalog(Assembly.GetCallingAssembly()));
    }
    public void Start(TParams parameters)
    {
        var startables = _container.GetExportedValues<IStartable<TParams>>();
        foreach(var startable in startables)
        {
            startable.Start(parameters);
        }
    }
    public void Start()
    {
        Start(default(TParams));
    }
    public void Stop()
    {
        if (_container == null)
        {
            throw new InvalidOperationException("Stop can only be called once");
        }
        _container.Dispose();
        _container = null;    
        
    }
}
[InheritedExport]
public interface IStartable<TParams>
{
    void Start(TParams parameters);
}

CompositionStarter<TParam> creates a container (or uses the one that you pass in). On the Start method it pulls all IStartable<TParam> exports from the container and invokes their Start methods passing in the parameters. With CompositionStarter in place, I can now introduce a WpfStartable and move the code for importing and displaying the window there.

public class WpfStartable : IStartable<object>
{
    [Import]
    public Window Window { get; set; }
    public void Start(object parameters)
    {
        Application.Current.MainWindow = Window;
        Window.Show();
    }
}

The app class can then be updated to use the following starter code:

void App_Startup(object sender, StartupEventArgs e)
{
    var starter = new CompositionStarter<object>();
    starter.Start();
}

The code is no longer app-specific, nor is it specific to a particular UI platform. The same code pattern also works for a Silverlight application, a WinForms application or a console app.

Notice that CompositionStarter pulls multiple IStartable implementations. This allows me to introduce other pluggable startup operations.

A note about Silverlight and PartInitializer

In Silverlight we have introduced PartInitializer which automatically bootstraps a shared container and composes an existing instance. This is primarily for usage in places such as XAML where objects are created by the XAML parser, but need to get composed. PartInitializer may be sufficient for your startup needs in Silverlight so if it works, don’t feel compelled that must use CompositionStarter, you don’t.

You may want to combine the two approaches. The benefits of doing this are you could have CompositionStarter bootstrap your app, while still using PartInitializer within XAML elements that need composition.

PartInitializer allows you to override its default container through the CompositionHost.InitializeContainer method. This means you can create a container that is shared by both PartInitializer and the CompositionStarter class.


void App_Startup(object sender, StartupEventArgs e)
{
    var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetCallingAssembly()));
    var container = new CompositionContainer(catalog);
    CompositionHost.InitializeContainer(container);
    var starter = new CompositionStarter<object>();
    starter.Start();
}

Using MEF within XAML in WPF

In the previous section I spoke about the PartInitializer API which we baked into Silverlight for composition in XAML, it lets you write code such as the following:

public partial class Dashboard : UserControl
{
    public MainPage()
    {
        InitializeComponent();
        PartInitializer.SatisfyImports(this);
        foreach (var widget in Widgets)
            TopWidgets.Items.Add(widget);
    }
    [ImportMany]
    public UserControl[] Widgets { get; set; }
}

Above Dashboard is a user control that is created within XAML. It imports a collection of widgets. It forces itself to be composed by calling PartInitializer.SatisfyImports().

This is great for Silverlight, but what about WPF? Although we don’t yet have it in the box, I’ve ported our PartInitializer implementation to WPF. The functionality is almost identical though instead of looking in the main application XAP, it looks in the bin folder of the application and an optional extensions folder. You can get it on my skydrive here.

Alternatively you can have the control which hosts Dashboard compose it by calling ComposeParts on the container and pass it in. Another option is to pass a container through the visual tree as an attached property and then have a helper method / another attached property which allows Dashboard to get composed without depending on a static container. More on this in another post.

Hosting MEF within a library

We’ve discussed an approach for hosting within an application, but what about a library? Should you use CompositionStarter then? I would err against that as it’s not ideal. For example take the case of a rules engine that uses MEF to discover rules. The rules engine itself needs the rules, so delegating off to IStartables to get the rules adds extra complexity with little gain. Having the rules engine host a container which it uses to get the rules is not at all a problem. Here is one way to implement it.

public class RulesEngine
{
    private readonly CompositionContainer _container;
    private RulesEngineImports _rulesEngineImports;
    public RulesEngine()
    {
        if (_container == null)
            _container = new CompositionContainer(new AssemblyCatalog(Assembly.GetCallingAssembly()));
        var imports = new RulesEngineImports();
        _container.ComposeParts(imports);
    }
    public RulesEngine(CompositionContainer container)
    {
        _container = container;
    }
    public RulesEngine(params ComposablePartCatalog[] catalogs)
    {
        var aggregate = new AggregateCatalog(catalogs);
        _container = new CompositionContainer(aggregate);
    }
    private class RulesEngineImports
    {
        [ImportMany]
        public IRule[] Rules { get; set; }
    }
}

RulesEngine’s default ctor creates a default container though it accepts overrides for passing in a container and catalogs, this allows containers to be shared across other libraries that might use MEF. Once RulesEngine is created, the default ctor then creates a new RulesEngineImports class which it then composes. This class is basically a buddy class to get the imports that RulesEngine needs.

Note: I could have put the imports directly on RulesEngine, but in Silverlight these have to be public members as private reflection is not supported. I don’t want to expose the engines internal implementation to the outside and I want the engine to be reused in SL and WPF. Using this approach allows that reuse by keeping the imports as an internal implementation detail.

Why not use CommonServiceLocator?

I know there are going to be a bunch of folks reading this saying why should you couple the RulesEngine to MEF? Can’t you just use CommonServiceLocator to get the rules the engine needs? Yes you absolutely could do that, though it will limit the capabilities you can leverage from a specific container. For example MEF currently supports metadata views on imports, something that is currently specific to MEF, though Autofac is catching up quickly :-) Additionally using CSL often results in icky service locatorish code all over the place, something we (the founders of CSL) never intended but which has happened.

An alternative to using CSL that supports any container is to have an app-specific IRulesEngineServiceAdapter export which returns all the dependencies / imports that the engine needs. The service adapter can use whichever IoC it chooses, and it can leverage the full capabilities of that container. The engine could still use MEF to discover the adapter and then use the adapter from there on.

public class RulesEngine
{
    private readonly CompositionContainer _container;
    private IRulesEngineServiceAdapter _adapter;
    public RulesEngine()
    {
        if (_container == null)
            _container = new CompositionContainer(new AssemblyCatalog(Assembly.GetCallingAssembly()));
        _adapter = _container.GetExportedValue<IRulesEngineServiceAdapter>();
    }
    public RulesEngine(CompositionContainer container)
    {
        _container = container;
    }
    public RulesEngine(params ComposablePartCatalog[] catalogs)
    {
        var aggregate = new AggregateCatalog(catalogs);
        _container = new CompositionContainer(aggregate);
    }
}

In the MEF case, the adapter would simply be a part which imports the rules. For other containers the implementation would differ.

[InheritedExport]
public interface IRulesEngineServiceAdapter
{
   IRule[] Rules { get; set; }
}
public class MefRulesEngineServiceAdapter : IRulesEngineServiceAdapter
{
    [ImportMany]
    public IRule[] Rules { get; set;}
}

Hosting MEF within a web application or a web service

Using MEF within a multi-request server application such as a web app or a WCF service is a whole other ball of wax. You can use CompositionStarter in limited scenarios as long as you are dealing with singletons shared across all requests. For more sophisticated scenarios you will need to create scoped per-request containers. That is outside of the scope of this post, but we will likely have future posts on this topic.

Recap

We’ve just dug in to what it means to host MEF within an application / library, and various approaches for doing so. My goal for this post was simply to illustrate a range of options, use them or leave them depending on whether or not they work for your scenario. Don’t try to force a square peg into a round hole!

Exporting dynamically changing configuration values

Glenn Block MSFT — Sun, 31 Jan 2010 21:46:25 GMT

In my last post I discussed how to export configuration. A follow up question in the comments was “What if the values change?” Meaning the values that are exported using the approach I illustrated are static. In the real world however values often can change based on some user setting etc. A variant of the approach however allows the values to not be static. Instead of exporting a value, export a Func which returns the value. MEF offers nice support for this through method exports. For example to allow the “recently used file” config item to change over time, we can modify the Exporter to export that value as a method rather than a property.

public class RecentlyUsedTrackerConfiguration
{
  private IConfigurationProvider _provider;
  [ImportingConstructor]
  public RecentlyUsedTrackerConfiguration(IConfigurationProvider provider)
  {
     _provider = provider;
     MaxItems = provider.GetValue<string>("recentlyUsedTracker.maxItems");
  }
  [Export("RecentlyUsedTracker.File")]
  public string GetFile() {
    return _provider.GetValue<string>("recentlyUsedTracker.maxItems");
  }
  [Export("RecentlyUsedTracker.MaxItems")]
  public int MaxItems {get;private set;}
}

Instead of exporting a property, we are now exporting the GetFile method. Method exports are imported as delegates, thus RecentlyUsedTracker now looks like this.

[Export]
public class RecentlyUsedTracker {
  [Import("RecentlyUsedTracker.File")]
  public Func<string> File {get;set;}
  [Import("RecnetlyUsedTracker.MaxItems")]
  public int MaxItems {get;set;}
}

Notice above we are importing a Func<string> for the File item rather than string. This gives us the hook to dynamically change File each time it is accessed. You could even go further an parameterized File if you wanted to pass in context to determine which File is returned.

It’s still easy to test

With this approach RecentlyUsedTracker is still easy to test. With lambda syntax it is pretty painless to pass in test values when the class is under test.

How do I expose configuration information through MEF?

Glenn Block MSFT — Wed, 27 Jan 2010 19:00:26 GMT

This question which recently popped on our forums is one of the common questions we hear from customers. In this particular case, wcoenen (the person in the forums) had recently used information that he wanted to pull from configuration and pipe to a part. He solved the problem by creating a special configuration provider service which he injected into the part to provide the config. The code for the consumer looked like this:

[ImportingConstructor]
public RecentlyUsedTracker(IConfigurationProvider configurationProvider)
{   
  this.recentlyUsedFile = configurationFile.GetValue<string>("recentlyUsedTracker.File");   
  this.maxItems = configurationProvider.GetValue<int>("recentlyUsedTracker.maxItems");
}

As you can see above RecentlyUsedTracker takes an import of configuration provider. The solution above does work. The biggest issue wcoenen raised is that coupling of the part to the config provider makes testing more difficult. It requires a mock service to be passed in to every test. Another subtlety is that you won’t know if the data is actually present until the code executes.

An alternative approach, use property exports.

A different way to approach this problem is to actually export the individual configuration values. We can still use the generic configuration provider, but we can keep a nice separation of concerns. The part can then import these values like any other import. MEF provides a very powerful facility for doing this called property exports. A property export is a property which is decorated with an export attribute. It is special because it provides a place for you to execute custom logic for retrieving a value and returning it to MEF, i.e. a custom factory. This is a different model than the traditional class-level exports which MEF is responsible for the creation . So using a property export we can easily surface configuration information and we can use any method we choose to get the value including the provider. For example, take a look at the code below.

public class RecentlyUsedTrackerConfiguration
{
  private IConfigurationProvider _provider;
  [ImportingConstructor]
  public RecentlyUsedTrackerConfiguration(IConfigurationProvider provider)
  {
     _provider = provider;
     File = _provider.GetValue<string>("recentlyUsedTracker.file");
     MaxItems = provider.GetValue<string>("recentlyUsedTracker.maxItems");
  }
  [Export("RecentlyUsedTracker.File")]
  public string File {get;private set;}
  [Export("RecentlyUsedTracker.MaxItems")]
  public int MaxItems {get;private set;}
}

RecentlyUsedTrackerConfiguration IS a part as you can see it has an importing constructor which takes a provider. But instead of exporting itself, it exports it’s properties which use the provider to get the values. It then assigns a string contract to each export which correlates to the configuration item it is exporting.

Note: You can make this more compile safe, by using constants or creating custom export attributes

Now let’s take a look at our consumer.

[Export]
public class RecentlyUsedTracker {
  [Import("RecentlyUsedTracker.File")]
  public string File {get;set;}
 
  [Import("RecnetlyUsedTracker.MaxItems")]
  public int MaxItems {get;set;}
}

RecentlyUsedTracker imports File and MaxItems. It’s nice and clean (aside from the attributes :-) ). We can now easily test RecentlyUsedTracker, as he has no dependency on a provider. All he cares about is that the exports he needs are in the container.

An additional benefit the above approach introduces.

If you read my my or Nick’s blog’s, then you’ve heard us talk about Stable Composition and Rejection. Parts that don’t have there required dependencies are rejected. That means that RecentlyUsedTracker will be rejected unless the config items he needs are present. It’s consistent with the way the rest of MEF works it ensures consistency of the system. Of course if you want to allow the part to be created even though the data is not present, you can always set the AllowDefault property on Import = true.

What else can use this approach for?

Using property exports has a million and one uses. Any time you need to integrate legacy or non-MEF components to MEF, property exports are usually a sure win! For example, let’s say you have an existing third-party class which you use in your system which is sealed. You can create that class in a property export and surface it to MEF. It’s also a great way to surface singletons that you don’t want parts to depend on. What do I mean? Check the code below as an example.

public class ApplicationPart
{
  [Export]
  public Application App {
    get{ return Application.Current;
  }
}

Any questions?

MEF and Prism exploration, MEF module loading

Glenn Block MSFT — Sun, 03 Jan 2010 18:05:30 GMT

About a month ago I posted some ideas around MEF and Prism together. As part of the post, I presented 2 high-level scenarios for MEF/Prism integration (and there are likely more)

Use Prism with MEF as an add-on for extensibility. That is make modules extensible through MEF. You can think of this as the “Two worlds in harmony” solution. Your core architecture rests on Prism's modularity / and an IoC Container and sits side by side with MEF.

Use MEF primarily for modularity, and pull in Prism bits for UI composition. In this model, your core architecutre sits on top of MEF, with MEF replacing the services of your IoC.

Recently Jeremy Likeness of Wintillect started exploring the first approach. He’s started a series of blog posts on his explorations down that path. If you check the series you’ll see how he is introducing a new type of module called a PartModule that then uses MEF. The approach he takes is nice because it uses all of the existing Prism module loading infrastructure including Unity, and then adds on that when the module is received, it is registered through MEF. He also leverages MEF’s recomposition capabilities such that when new things are received, they automatically show up as recomposable parts are recomposed.

Jeremy has 3 posts in the series so far, the content is nice and it includes all the code.

PRISM, MEF, and MVVM Part 1 of 3: Unity Glue

PRISM, MEF, and MVVM Part 2 of 3: Making PRISM MEF Friendly

PRISM, MEF, and MVVM Part 3 of 3: Dynamic MEF Modules in PRISM

This is just one of what I am sure will be many explorations to come!

“MEF in 2 hours or less”, I am all for it.

Glenn Block MSFT — Thu, 31 Dec 2009 00:42:00 GMT

Some posts titles just really grab you. I couldn’t help but think about one of those annoying ads in the back of magazine when I saw this post from Ayende. In actuality the article is more of a “How I can implement what I need from MEF in 2 hours” however that’s not as provocative :-)

The main point Ayende makes in the article is that folks talk about specific features in MEF like dynamic discovery and lazy loading as big deals, and he can implement something similar in a few hours. As I mentioned in the comments, I think Ayende is over generalizing on exactly what capabilities MEF actually provides, but I have no problem with that statement, just as I had no issue with Jeremy saying “Build your own CAB”. I went on to say (paraphrasing) “MEF is not built for you, it’s for the ecosystem”.

What I mean by that is this, MEF is designed for supporting a rich ecosystem of extenders, it establishes a standard for extensibility that crosses application boundaries. If you are a third-party extending an application built on MEF, you just need to speak the language. You can walk up to any application that speaks that language and you are golden. Eclipse / OSGI is a prime example of this (not talking about the Experience but the extensibility). Visual Studio’s Editor in 2010 is another prime example.

With MEF we’re saying you don’t have to be Eclipse / Visual Studio to provide the same type of experience. With MEF you can get off the ground with a few keystrokes, and without reading a 200 page manual. Of course that just gets you in the door, and as you scale up to use more advanced features MEF get’s more complex in fact, if you get to the Primitives you almost need to be a rocket scientist. However, you have a dial. If all you want to start with is using MEF for loading a small collection of plugins, you can do that with ease. Over time you can scale up according to your needs. As you scale you may find many of those features that you may not need today are a welcome addition.

Now back to Ayende’s comment, if you are not using MEF for it’s ecosystem enabling capabilities, and you do not find the features it provides adequate, then feel free to NOT use it. Don’t worry, we’re not going to send the MEF police to your door! (Though don’t be surprised if I ping you personally over IM :-) )

I am not saying that to drive you away from MEF, I am saying that saying NO is a valid option if it doesn’t meet your needs, and you can find/create something that does. If it does however meet your needs, saying no “just because” is silly.

I’ll close with this statement, there’s much more to MEF than meets the eye. I advise taking it for a ride before you discard it.

Building Hello MEF – Part III – XAP Partitioning (with the host’s permission) and the sweetness of recomposition.

Glenn Block MSFT — Tue, 15 Dec 2009 21:31:00 GMT

In our last post we saw how using metadata in MEF allows us to provide additional self-describing information about exports. This has a range of uses including providing hints on how the export should be handled (such as UI location) as well as allowing us to filter out creating exports that we don’t need or which are not relevant to the current application context. In this post, we’ll see how we can now take our parts which all currently reside in a single XAP and we can split them up into multiple XAPs. We can use this for several reasons including reducing the general download time of our application, as well as allowing third-parties to extend our Silverlight applications. We’ll also see how we can combine dynamic download with a winning feature in MEF called recomposition.

Just to remind you, this is what our dashboard looked like when we left off.

You can get the code for where we left out here

For our next exercise, we’re going to do something contrived though this is “based on a real story”, don’t worry. We’re going to take our dashboard app and extend it so that when we hit the “Hello MEF” button, new parts show up that are dynamically downloaded from a separate XAP on the server. I’ll show you two different ways of doing this, in this post we’ll do it with the host’s permission and in the next post without.

Below is a diagram of what this looks like.

Where is the dynamic XAP download support in MEF? I don’t see it.

If you are familiar with MEF’s apis in Silverlight 4, you might be asking this question. The question is a valid one. The reason you don’t see it, is because it’s not there ;-) Instead we have initially shipped this feature as part of the Silverlight 4 Beta Toolkit, which you can download here. You’ll need this to follow along on this post.

Introducing the Package apis

If you download the toolkit, you’ll find our dynamic XAP support in the System.ComponentModel.Composition.Packaging.Toolkit.dll. The apis are below.

    public class Package
    {
        public Package(Uri packageUri, IEnumerable<Assembly> assemblies);
        public IEnumerable<Assembly> Assemblies { get; }
        public static Package Current { get; }
        public Uri Uri { get; }
        public static void DownloadPackageAsync(Uri packageUri, Action<AsyncCompletedEventArgs, Package> packageDownloadCompleted);
    }

    public class PackageCatalog : ComposablePartCatalog, INotifyComposablePartCatalogChanged
    {
        public PackageCatalog();
        public IEnumerable<Package> Packages { get; }
        public override IQueryable<ComposablePartDefinition> Parts { get; }
        public event EventHandler<ComposablePartCatalogChangeEventArgs> Changed;
        public event EventHandler<ComposablePartCatalogChangeEventArgs> Changing;
        public void AddPackage(Package package);
    }

The api has two parts. First there is the Package class. Package has a static method called DownloadPackageAsync which you pass a Uri for a XAP as well as a completed action. As soon as you call this method, MEF will begin the download. Once the XAP is received, it will invoke the callback passing in an instance of Package. In the callback handler, the next step is to add the Package to a PackageCatalog. In order for MEF to see the PackageCatalog it must have been added to an instance of MEF’s container. Until now we’ve avoided talking about the container but well learn a bit about it shortly. Once the new package is added, it will then be available to parts in the container. We’ll see how with recomposition, parts that import any of the exports in the new package will suddenly “light up” with the newly available parts.

OK, let’s get going.

Creating a separate XAP.

The first thing we need to do to get going is create a separate XAP. You might be surprised if you go looking for the “Create Secondary XAP” template, as there is none :-) However, all hope is not lost. Fortunately we can create a XAP by using the Silverlight Application template. Right click on the HelloMEF solution can click “Add New Project”. Enter HelloMEF.Extensions as the project name.

Once you do, hit OK on the next page and you’ll get a new Silverlight application. Next go into the project and remove the App.Xaml and

One last step, we need to set our web application so it copies our new XAP to the output folder. Fortunately the tooling support for SL4 brings this to VS2010 out of the box. If you right click on the HelloMEF.Web project and check the “Silverlight Applications” tab, you’ll see.

I am guessing this was not intended for the application partitioning solution and was rather for having multiple Silverlight applications in a single web application. However, it works great for our scenario so we’re not complaining!

Once you create the new application, VS automatically creates a new start page in your web site which it sets as the default. We need to reset it back, so go right-click on HelloMEFTestPage.html under HelloMEF.Web and set it as the startup page.

Create a contract assembly

Now that we’ve created our separate XAP, we can now go start building our new extension. OK, all we do is go and create our widget, but wait, how do we get access to the Widget contract? Currently all the widget definition information resides in the app. We could just go and a reference back to the application right? Technically you could as the app won’t be referencing us directly, but please DON’T do it. Every time you do a puppy dies :-)

What we need to is to split our contracts out into a separate assembly so that those definitions can be shared across XAPs. We don’t have to embed the shared library over and over fortunately.

First thing we’ll do is create a new Silverlight Class library project. You know the drill, right click the solution, new project…

Delete the Class1.cs file. Then go cut/paste ExportWidgetAttribute.cs, WidgetLocation.cs and IWidgetMetadata.cs from the HelloMEF project into HelloMEF.Contracts. You will then need to add a reference to System.ComponentModel.Composition (which should be in your recent references) in the new project. Remember it’s in the “.\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client folder.

Next go add back to the HelloMEF project and add a reference to the new HelloMEF.Contracts assembly.

Compile the project. If you followed each of the above step correctly it “should” compile. If it doesn’t work, you can grab a working version here

Building a dynamically downloadable widget

First we need to add a reference to MEF in our HelloMEF.Extensions project as we did above. Next we’ll add a reference to HelloMEF.Contracts. After adding it, go right-click on the reference and set Copy-Local to false in the reference properties. As our shared library is referenced by the app we know it will be loaded into memory and we shouldn’t copy the assembly over and over. If we do, we could run into trouble.

Now go add a new UserControl to the HelloMEF.Extensions project. Call it Widget3. We’ll make this have a textbox with a green border. Below is the Widget3.xaml.

<UserControl x:Class="HelloMEF.Extensions.Widget3"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    
       <Grid x:Name="LayoutRoot" Height="Auto">
            <TextBox Background="Green" Text="Hello MEF!" TextAlignment="Center" Height="100" Width="300"/>
       </Grid>
</UserControl>

Next go drop in the code behind and make it a widget.

namespace HelloMEF.Extensions
{
    [ExportWidget(Location=WidgetLocation.Bottom)]
    public partial class Widget3 : UserControl
    {
        public Widget3()
        {
            InitializeComponent();
        }
    }
}

Initializing the container to support dynamic download

If you are new to MEF, you might not be aware that behind the scenes the PartInitializer uses a class called the CompositionContainer to do all the work. By default we create a container which has all the exports in the current XAP. You can however override that container to do special things, like support dynamic XAP download. You override the container by calling the CompositionHost.InitializeContainer method.

Add the following code to the App.xaml.cs class in the main app.

private void InitializeContainer()
{
    var catalog = new PackageCatalog();
    catalog.AddPackage(Package.Current);
    var container = new CompositionContainer(catalog);
    container.ComposeExportedValue(catalog);
    CompositionHost.InitializeContainer(container);
}

The code above is performing several functions.

It creates a PackageCatalog. Catalogs are a generic concept and they provide parts to the container. In this case the PackageCatalog will provide parts found in XAPs. Future downloaded XAPs will get added to this catalog.
It adds Package.Current, which contains all the assemblies in the main XAP.
Creates a container which uses the new catalog.
Composes the catalog into the container. This makes the PackageCatalog available to importers so they can use it. You can also wrap the PackageCatalog in a service like IPackageService if you like and export it that way, but I am keeping it simple.
Finally it overrides PartInitializer’s container with this new container.

Now we have one more thing to do which is to call our new method. Replace the Application_Startup method with the following code.

private void Application_Startup(object sender, StartupEventArgs e)
{
    InitializeContainer();
    this.RootVisual = new MainPage();
}

Now compile and run the app to test that the overridden container is working. You should the same result.

Enabling a widget to download new widgets

We’ve added our widget, but it’s not showing up, why? Well, because we haven’t used the Package class to download it. Let’s do that now. First thing we need to do is add a reference to the packaging dll. You’ll need to look in your Toolkit folder.

Next we’ll change Widget1 to go and download our new widgets. We’ll start with adding a using statement for System.ComponentModel.Composition.Packaging at the top, and then we’ll implement the logic.

using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;
using System.ComponentModel.Composition.Packaging;
namespace HelloMEF
{
    [ExportWidget(Location=WidgetLocation.Top)]
    public partial class Widget1 : UserControl
    {
        [Import]
        public PackageCatalog Packages { get; set; }
        public Widget1()
        {
            InitializeComponent();
            Button.Click += new RoutedEventHandler(Button_Click);
        }
        void Button_Click(object sender, RoutedEventArgs e)
        {
            Package.DownloadPackageAsync(new Uri("HelloMEF.Extensions.xap",UriKind.Relative), (args, p) => Packages.AddPackage(p));
        }
    }
}

Here’s what we’ve done.

We added an import to get to our PackageCatalog that was explicitly added to the container.
We’ve subscribed to the button click event.
In the handler, we’ve used the static Package.DownloadPackageAsync method to grab “HelloMEF.Extensions.xap”. The method takes a delegate, which we are passing a lambda to for adding the package upon it’s receipt.

Now compile and run the app. Once the app is running, press the button and…….Exception!

What’s happening is our new package has been downloaded, but it has been rejected by MEF, why? Oh, due to non-recomposable import, of course :-) What in the world is that? :-) Let’s scroll and look at the rest of the exception.

What MEF is basically saying here is that new exports have showed up in our XAP which will satisfy the import MainPage.Widgets, but they have been rejected because the Widgets import itself is not recomposable.

Rejection and Recomposition

We just saw two things coming into play here. First MEF rejects things sometimes. In this case it is rejecting the new parts in the catalog due to recomposition, but it will also reject for other reasons such as a part having an import which cannot be satisfied because no exports are present. Rejecting is part of a very powerful feature called Stable Composition feature which we built MEF on top of and which your systems can rely on. For more on Stable Composition, check this post.

But what is Recomposition? Recomposition means that parts in MEF are not static once they are composed and they can opt in to be recomposed as new things show up, recomposed means all recomposable imports are re-satisfied. If you connect the dots, that means your systems on top of MEF are dynamic. There’s one caveat though, you have to opt-in to recomposition, otherwise parts are rejected.

Doing that is as simple as setting AllowComposition = True in the Import / ImportMany attribute as we’ve done below.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
            foreach (var widget in Widgets)
            {
                if (widget.Metadata.Location == WidgetLocation.Top)
                    TopWidgets.Items.Add(widget.Value);
                else if (widget.Metadata.Location == WidgetLocation.Bottom)
                    BottomWidgets.Items.Add(widget.Value);
            }
        }
        [ImportMany(AllowRecomposition=true)]
        public Lazy<UserControl,IWidgetMetadata>[] Widgets { get; set; }
    }
}

Now run the app, press the button and we don’t get an exception.

Awesome, but aren’t we back where we started? There’s no new widget, where is it?

Designing for Recomposition

The widgets are there, they are just not showing. Why? Because we populated the widgets when the control loaded. The Widgets property has been updated, but the MainPage doesn’t know to do anything when it is. What we need to do is make some changes to our MainPage to make it recomposition aware. There are two ways we could do this. First we could change our auto property to a real property, and override the getter when it is set. This is a bit ugly, so let’s not do that.

Instead let’s take advantage of an interface in MEF which although it has a hideous name, is very nice. It’s called IPartImportsSatisfactionNotification :-) What it does is allow the part to get notified by MEF whenever recomposition occurs. Thus, the perfect place for our logic for populating the widgets, AND we can still use automatic properties.

Below is the code for MainPage to do this.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl, IPartImportsSatisfiedNotification
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
        }
        [ImportMany(AllowRecomposition=true)]
        public Lazy<UserControl,IWidgetMetadata>[] Widgets { get; set; }
        #region IPartImportsSatisfiedNotification Members
        public void OnImportsSatisfied()
        {
            TopWidgets.Items.Clear();
            BottomWidgets.Items.Clear();
            foreach (var widget in Widgets)
            {
                if (widget.Metadata.Location == WidgetLocation.Top)
                    TopWidgets.Items.Add(widget.Value);
                else if (widget.Metadata.Location == WidgetLocation.Bottom)
                    BottomWidgets.Items.Add(widget.Value);
            }
        }
        #endregion
    }
}

You can see now that when composition occurs, we are clearing our two controls and repopulating. In future post we’ll see how we can use a ViewModel to make this code much cleaner.

OK, drum roll please. Compile and Run the app, press the button and….

Voila, dynamic download of XAPs!

A few caveats about our Package API

I am sure by now you are thinking, wow this looks great! However, there are some unsupported capabilities when using our Package API that you should be aware of.

Does not support Silverlight caching. Meaning if your XAP has references to things that are not in the XAP, the will only be found if they have been previously loaded, as the contracts are because the main app references them.
Does not support loose resources such as images, xaml files, etc sitting in the XAP. They must be resources embedded in assemblies.
Does not support versioning. Let’s say you have a XAP that uses version 1 of a type, and another XAP that uses version 2. The loader will load both rather than unify on the latest version.
Does not support localization, though you can probably come up with your own localization mechanism.

Summary

In this post, we learned how we can add dynamic XAP downloading support to our applications.

Along the way we also learned the following:

MEF has a CompositionContainer behind the scenes which it uses for composition. This container can be overridden.
MEF Contracts can be shared across XAPs and do not need to be embedded in every XAP.
MEF rejects parts that it cannot work with.
MEF supports recomposition allowing parts to be recomposed when new things show up.
IPartImportsSatisfiedNotification allows us to get notifications within our parts when they are recomposed.

This opens up a Pandora’s box of power. It can be used for good or evil :-) On the good side we can use it to allow our Silverlight apps to be extended by third-parties, as well as to partition our apps for a better user experience.

What’s next

In the next post we’ll explore this scenario a bit further. We’ll see how you can create a part that dynamically downloads XAPs without needing PartInitializer to be configured to allow it. MEF on!

Code is attached.

Building Hello MEF – Part II – Metadata and why being Lazy is a good thing.

Glenn Block MSFT — Sat, 05 Dec 2009 01:47:00 GMT

In Part I of the series we built the basics of our dashboard end ended with our app displaying a single widget. In this post we’ll show two widgets, sensing a pattern here? :-) We will show two, but we’ll put them in different places on our dashboard. We’ll explore two ways of doing this including a very powerful feature in MEF called metadata. Then we’ll see how we can use custom exports to provide our own “language’ of sorts for our extenders.

If you are just jumping into this post, you can grab the code for where we left off here.

Adding a second widget

OK, here we go. Now that we have our dashboard infrastructure in place, should be easy to add a second widget right? Right. Let’s do it, this time we’ll add a text box.

First we’ll go create a new user control called Widget2

Next we’ll go into the Widget2.xaml and add a button with the content “Hello MEF”.

<UserControl x:Class="HelloMEF.Widget2"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    
    <Grid x:Name="LayoutRoot" Height="Auto">
        <TextBox Text="Hello MEF!" TextAlignment="Center" Height="100" Width="300"
    </Grid>
</UserControl>

Then we’ll jump into Widget2.xaml.cs and add our export.

using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;
namespace HelloMEF
{
    [Export(typeof(UserControl))]
    public partial class Widget1 : UserControl
    {
        public Widget1()
        {
            InitializeComponent();
        }
    }
}

All we did was create a new control and drop an export (the only MEF port). Let’s run it.

Presto! The second widget shows up. No app.config editing, no explicit registration code. Just add it to the project and we’re done. Not bad!

Adding a second widget where we want it, and why being Lazy is a good thing.

OK well that’s pretty nice. But if you read my first post, we want to have widgets showing up in different places as we have 2 panels for widgets in our screen. One which is blue, and one which is yellow but currently invisible. So what can we do? Well one option is to create different interfaces, ITopWidget, IBottomWidget. Then we can check if the class implements those interfaces once we get it and just put it in the right place.

If we did, our code would in our MainPage would look something like this

public MainPage()
{
    InitializeComponent();
    PartInitializer.SatisfyImports(this);
    foreach (var widget in Widgets)
    {
        if (widget is ITopWidget)
            TopWidgets.Items.Add(widget);
        else if (widget is IBottomWidget)
            BottomWidgets.Items.Add(widget);
    }
}

That works, however it forces us to ship new interfaces every time I we want to enhance the UI and add a left pane, we need to ship ILeftWidget. A different problem is that we are creating all widgets even if they don’t implement any of our interfaces. But what else can we do?

Lazy

The answer is to become Lazy. Yes folks, this is the one time when Lazy is a good thing. If you are not familar, Lazy<T> is new type in the SL4 and FX4 BCL that allows you to delay the creation of an instance. MEF fully supports Lazy, thus you can import single values and collections in a delayed manner. For example we can change our ImportMany to use Lazy, by pasting the following code in MainPage.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
            foreach (var widget in Widgets)
            {
                TopWidgets.Items.Add(widget.Value);
            }
        }
        [ImportMany]
        public Lazy<UserControl>[] Widgets { get; set; }
    }
}

Two things you should notice above, first our Widgets import is now an array of Lazy<UserControl>, and second in the loop we are adding widget.Value rather than the widget value directly. What is going on here is instead of importing UserControl instances we are importing lazy references to our widgets. The first time Value is accessed, the UserControl is created, thus we access .Value to add the widgest to the TopWidgets ItemsControl.

Metadata

Well that’s nice, because now we’ve delayed creating the controls until we actually need them. The downside is we have no way to determine which one’s we should put where which was our goal. And THAT is where metadata comes to the rescue. Not only does MEF support lazy instantiation, but it also supports a concept called export metadata. This means that a MEF export can give off additional information about itself that the importer can use for several reasons, whether it be determining whether or not it should be created, or in our case determining where it will show on the screen. The importer can access this information BEFORE the instance has actually been activate. This means if the particular export does not match the requirements, then it does not have to be created.

Metadata is arbitrary in MEF, that means you can use it however you see fit according to your application needs. Using metadata has two parts, first there is the exporter who defines which metadata is available for importers to look at. Then there is the importer who is able to access the metadata at the time of import.

Defining the metadata for widgets

In our case we want our widgets to provide us a location. In order to do that, we’ll first create a new enum called WidgetLocation.

namespace HelloMEF
{
    public enum WidgetLocation {Top, Bottom}
}

Then we’ll go add a piece of metadata called Location to our widgets. There are several ways to do this in MEF, the easiest of which to start with is simple adding an ExportMetadata attribute. First we’ll go to Widget1.xaml.cs and set the widget’s location to the top as you can see below. Notice, the key and value are arbitary to my specific needs.

    [ExportMetadata("Location", WidgetLocation.Top)]
    [Export(typeof(UserControl))]
    public partial class Widget1 : UserControl
    {
        public Widget1()
        {
            InitializeComponent();
        }
    }

Next we’ll go to Widget2 and tell it to set it’s location to the bottom.

    [ExportMetadata("Location", WidgetLocation.Bottom)]
    [Export(typeof(UserControl))]
    public partial class Widget2 : UserControl
    {
        public Widget2()
        {
            InitializeComponent();
        }
    }

Now we can move on to the importer

Giving the dashboard access to the widget metadata and why Lazy has a brother.

Now that we’ve defined the metadata we just need to use it. We talked about Lazy<T>, let’s talk about it’s brother Lazy<T,M>. In order to allow us to access the metadata, MEF introduces a special kind of Lazy, one that has attached metadata. M in this case is an interface (we call it a metadata view) that contains only getter properties where the property name corresponds to the key of a piece of metadata. MEF will automatically general a proxy class that implements this interface and it will plug all the metadata in for you. This is very cool! You need to see it to believe it (and understand it).

So let’s just do it rather than talking about it.

First, we’ll create a new interface call IWidgetMetadata which contains our Location metadata.

namespace HelloMEF
{
    public interface IWidgetMetadata
    {
        public WidgetLocation Location {get;}
    }
}

Next we’ll go into our MainPage.xaml.cs, and change our Widgets import to use the new metadata. We’ll also change the logic to place the widgets in the appropriate place.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
            foreach (var widget in Widgets)
            {
                if (widget.Metadata.Location == WidgetLocation.Top)
                    TopWidgets.Items.Add(widget.Value);
                else if (widget.Metadata.Location == WidgetLocation.Bottom)
                    BottomWidgets.Items.Add(widget.Value);
            }
        }
        [ImportMany]
        public Lazy<UserControl,IWidgetMetadata>[] Widgets { get; set; }
    }
}

Above you can see that Widget’s item type is now Lazy<UserControl,IWidgetMetadata>. Also in the for loop we’re accessing widget.Metadata.Location in a compile safe manner, but we never created a concrete class that implements IWidgetMetadata, did we? We didn’t, but MEF did :-) The result is no magic strings on the importer side, we get intellisense, refactoring and compile time checking! Also notice we still need to access the .Value to get the widget to be created. This is actually an advantage though because if we get a widget with a different location, it won’t get created wastefully. Here it makes no big difference, but if we had 50 widgets that is a different story.

Now we’ll go run the app.

And Voila we see our widgets are now going in the right place, and we didn’t have to do 1000 back flips.

Magic strings are bad! And MEF has an answer.

Notice above I mentioned we get all this compile time safety and intellisense support for the importer. But what about the exporter? Our widgets are still specifying magic strings for the keys. Not only that, but imagine if I have multiple pieces of metadata, then it’s not just one string, it’s many strings for each part. Plus I lose a lot of discoverability because I don’t know intuitively when I create a widget, what metadata keys make sense. Even if we create constants for the keys, we don’t know the type.

Wouldn’t it be really nice if we could just do this: [ExportWidget(Location=WidgetLocation.Top)] ? We wouldn’t need Export, and we wouldn’t need all those loose ExportMetadata attributes. It would be cleaner, and our code would be less noisy.

The good news is you can.

Custom exports

MEF let’s you create custom exports that include metadata. A custom export is just that, it’s your own export attribute with metadata, and it’s strongly typed.

Let’s create our new ExportWidgetAttribute.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
    public class ExportWidgetAttribute : ExportAttribute
    {
        public ExportWidgetAttribute()
            :base(typeof(UserControl))
        {
        }
        public WidgetLocation Location { get; set; }
    }
}

If we look above there are a few things to note:

ExportWidgetAttribute inherits from ExportAttribute. This is what tells MEF “Hey I am an export attribute”
The base constructor on Export is called passing in UserControl. This step is critical or MEF will default to the concrete implementation that the attribute was dropped on.
The attribute has a [MetadataAttribute] on it, this tells MEF this is not only an export but it also provides metadata. Now that this is applied, MEF will look at each public property on the attribute that I added, and will assume it is metadata, with the name being the key. In essence it will add an [ExportMetadata(“Location”,…)] with whatever value is specified for the property.
The attribute has an [AttributeUsage] attribute specifying the acceptable targets i.e. class in this case and that AllowMultiple = false. If we don’t do this, then MEF will assume multiple sets of metadata can exist and will return the metadata as an array.

Now we can go and change each of our widgets to use the new attribute.

First Widget1.xaml.cs

using System.Windows.Controls;
namespace HelloMEF
{
    [ExportWidget(Location=WidgetLocation.Top)]
    public partial class Widget1 : UserControl
    {
        public Widget1()
        {
            InitializeComponent();
        }
    }

And then Widget2.xaml.cs

using System.Windows.Controls;
namespace HelloMEF
{
    [ExportWidget(Location=WidgetLocation.Bottom)]
    public partial class Widget2 : UserControl
    {
        public Widget2()
        {
            InitializeComponent();
        }
    }
}

Our custom attributes our quite nice. No more specifying a contract, no more loose metadata, and it’s nice and compact. Also notice our usings above as well, no more need to specify System.ComponentModel.Composition…..it’s our attribute. This means our customers can get going using MEF without even knowing they are using it. We just send them OUR attributes and OUR interfaces, and they are good to go.

Go and press the magic run button and this what you get.

Any questions? :-)

In Summary

In this post we learned how we can use metadata and Lazy to do some pretty nice things with MEF. We can annotate our exports with information that importers can use to determine whether they want to use us, and how they should us (i.e. put me in the top location). We also learned how can create our own custom expors to offer a nice experience.

What’s next?

In the next post we’ll explore how to partition our apps into multiple XAPs and use MEF to deliver them on-demand. We’ll also learn a few other aspects of MEF that may not be obvious. There’s much more to come after that, the series is shaping up!

Code is attached

MEF and Prism, to be or not to be.

Glenn Block MSFT — Wed, 02 Dec 2009 23:58:00 GMT

Now to the question, what is the story on Prism and MEF? I am getting asked this now several times a day, more so than the IoC question.

I am happy to say we’re working with p&p to come up with a good answer.

Note: This is still a work-in-progress, but here’s the thinking on this so far.

There is some obvious overlap but also a clear delineation. In particular when it comes to UI composition. MEF can be used for UI composition for sure, however it doesn’t have specific UI composition bits like RegionManager, Composite Commands, EventAggregator. Something like EventAgg will come in the future, but it is highly unlikely we will ever deliver some of the Prism UI-specific bits as part of MEF. That could change, but at least today that is the case.

In general though here are the differences.

First, MEF is in the platform as part of SL4/FX4.
Second, MEF is a general UI agnostic composition technology while Prism is specific for UI composition. MEF also extends beyond composite applications to general extensibility / plugin models.
Third, Prism and MEF can work together.

There are two primary use cases we hear from customers who want to use MEF and Prism together.

Use Prism with MEF as an add-on for extensibility. That is make modules extensible through MEF. You can think of this as the “Two worlds in harmony” solution. Your core architecture rests on Prism's modularity / and an IoC Container and sits side by side with MEF.
Use MEF primarily for modularity, and pull in Prism bits for UI composition. In this model, your core architecutre sits on top of MEF, with MEF replacing the services of your IoC.

Note: You can also use MEF for some aspects of UI composition, particularly for pull-style regions which import their UI elements.

The first angle is primarily for customers who have existing applications that use Prism and want to use MEF. The second is for customers who are building new apps in SL4/FX4, that want to use MEF for providing the foundation, and pull in CAL libraries where appropriate. I think both make equal sense depending on customer needs.

In terms of which to use when, my advice is it depends on your situation.

If you are already committed to Prism, stick with it. There will be guidance coming for integrating MEF and Prism in Prism 4.
If you are starting fresh (and you are choosing to use MEF) then you may to use MEF for modularity, and general aspects of your composite app and pull in Prism pieces where appropriate.

MEF Refresh of Preview 8 for Silverlight

Glenn Block MSFT — Wed, 02 Dec 2009 23:35:58 GMT

Note: This only applies to using MEF Preview 8 on Silverlight, it does not apply to MEF in Silverlight 4

Yes I know we never did a Preview 8 post but……

We found a bug in PartInitializer (thanks to Kathleen Dollard for finding it!) in Preview 8 which affects MEF in Silverlight. The bug resulted in the default container that PI creates not being populated with any assemblies from the current XAP, which meant your imports would not get satisfied. This affected our Extensible Grid sample in that when you launched it you would not see any grid extensions.

The bug has now been fixed and we refreshed the release on 11/11.

Please download the latest bits to get the fix if you downloaded Preview 8 before the 11th.

Building the Hello MEF dashboard in Silverlight 4 - Part I

Glenn Block MSFT — Mon, 30 Nov 2009 10:28:00 GMT

In my last post I illustrated some of the basics of MEF through a Hello MEF dashboard app that I used in my PDC talk. In this series of posts, we’ll build that application from scratch and then go even further than we did in that talk. This might take several posts, I am not sure yet, we’ll just have to see ;-) We’ll build the app in an incremental fashion, revisiting different parts along the way in order to introduce new functionality.

Before you invest the time, I’ll give you a preview of the topics we’ll cover along the way.

Exports / Imports / Part Initializer – All that jazz
Export metadata
Custom exports
Overriding Part Initializer
Dynamic XAP downloading

In this post, we’ll cover just the first bullet.

To follow along, you will need Silverlight 4 and the Silverlight 4 toolkit. You can download Silverlight 4 beta here and the toolkit here.

The App

Below is a screenshot of the dashboard application.

May not look very complicated, but what we’re showing here is actually quite sophisticated. The dashboard itself is a dumb shell. The two “Hello MEF” widgets you see are actually exports that are discovered by MEF. The dashboard itself has not knowledge of what it will find, but it does know how to place things that are provided to it, and it has different locations on the screen where things can go. If you’re familiar with Prism, these are very similar to regions in principle though instead of modules pushing content into regions, MEF is pulling the content from whatever is available. More on this later.

Note: I’ll admit, I suck as a designer though I think I could be good if I REALLY try :-) Nice thing about SL is you don’t have to be, as your friendly neighborhood designer can make something hideous a work of art. With that note, don't expect a work of art out of this post.

Step 1 – Create the app

Nothing fancy here, just create a new Silverlight application. Enter HelloMEF as the name.

Leave the “Host the Silverlight application in a new Web Site” checked. We’ll use this later as we get into XAP partitioning.

Step 2. Create the dashboard UI.

For this dashboard we’re going to create something simple, amazingly simple, amazingly stupidly simple. But it works. We’ll create a StackPanel with two items control which will be populated with our widges. Jump into your MainPage.xaml and paste the following.

<UserControl x:Class="HelloMEF.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <StackPanel x:Name="LayoutRoot" Background="Black">
        <Border Background="Cyan">
            <ItemsControl x:Name="TopWidgets" Height="Auto" FontSize="30"></ItemsControl>
        </Border>
        <Border Background="Yellow">
            <ItemsControl x:Name="BottomWidgets" Height="Auto" FontSize="30"></ItemsControl>
        </Border>
    </StackPanel>
</UserControl>

Step 3. Find and show the widgets – Importing many

Our dashboard is supposed to populate itself with widgets. The first thing we need to think about is what exactly is a widget :-) In MEF when we have the concept of a contract. A contract represents something that will either be provided (exported) or consumed (imported). The easiest way to think about it for now is what type is the extension. In the case of our dashboard let’s just assume each widget is a UserControl. We could create a new base type or an interface, but we don’t need to. UserControl will do just fine.

So now we need to tell MEF we need a collection of UserControl, that is we want to import many UserControls. And for that we have the ImportMany attribute.

First add a reference to System.ComponentModel.Composition, and System.ComponentModel.Composition.Initialization.dll. To find them you’ll need to browse to your Silverlight SDK directory (C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client). Next go into the code-behind of MainPage.xaml.cs and overwrite the class with the following.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Basically we’re saying “MEF, give me the widgets”

Once we have the widgets, we need to show them on the screen. For now, let’s assume all widgets will go in the same ItemsControl. Let’s add the logic to the constructor.

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            foreach (var widget in Widgets)
                TopWidgets.Items.Add(widget);
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Step 4: Create a widget – Export

Now that we’ve got our basic Dashboard setup, let’s create a widget. Right click on the “HelloMEF” project and add a new Silverlight UserControl specifying Widget1 for the name.

Our widget is also going to be dead simple, and simply be a button. Go into Widget1.xaml and paste the following.

<UserControl x:Class="HelloMEF.Widget1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <Grid x:Name="LayoutRoot" Height="Auto">
        <Button x:Name="Button" Content="Hello MEF!" Width="300" Height="100"></Button>
    </Grid>
</UserControl>

Now we need to tell MEF that we want to provide our widget to importers of UserControl. To do this we will Export it. Go into HelloMEF.Widget1.cs and paste the following:

using System;
using System.ComponentModel.Composition;
using System.Windows.Controls;
using System.Windows;
namespace HelloMEF
{
    [Export(typeof(UserControl))]
    public partial class Widget1 : UserControl
    {
        public Widget1()
        {
            InitializeComponent();
        }
    }
}

Notice above we added an Export attribute and specified UserControl as the type. If we did not pass the type, then MEF would have just exported Widget1 as itself, which would not be of much use as the dashboard will never find it! That being said there are times when it does make sense to use the concrete type, but this is not one of them :-)

Step 5 – Compose the dashboard

OK, we’ve implemented our Dashboard, specified our imports, and created our widget. That means if we run the app, we’ll see widgets right? Wrong :-) Try running and you’ll see this nasty exception.

What happened? Our Widgets property is null, but why? The reason is because we never told MEF to do anything with it? Yes we put an ImportMany attribute, but MEF needs to somehow our MainPage in order to know it needs to provide anything. Which brings us to our last concept, composition.

In MEF there are basically 3 things you need to do. First two, declare your exports and imports which we did already. Third, tell MEF to actually go and compose, that is satisfy all imports. The places to do this (you can do it more than once) are where there are 1 or more imports and no exports. In this case our MainPage is the place where we import Widgets so that is the place.

Note: We won’t put it in the widgets themselves as they export themselves. Why not? Because when MEF pulls on an export, it automatically satisfies any of the imports on the thing it pulls. There is an exception to this, but we’ll cover it later.

In general whenever you have user controls that are created in XAML, you’ll use this technique. Telling MEF to compose in Silverlight takes only about 12 lines of code. It’s really easy code and 12 lines that are well worth it.

Kidding :-)

To tell MEF to compose you invoke a single call, PartInitializer.SatisfyImports(this). In MEF, anything that has imports or exports we consider a Part, which is why the name. Below is the code added in MainPage.cs

using System;
using System.Windows.Controls;
using System.ComponentModel.Composition;
namespace HelloMEF
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            PartInitializer.SatisfyImports(this);
            foreach (var widget in Widgets)
                TopWidgets.Items.Add(widget);
        }
        [ImportMany]
        public UserControl[] Widgets { get; set; }
    }
}

Now when we Run, we see our first widget show up.

Summary

OK, it’s 2:17 am, time to go to bed. I guess this will run several posts after all. :-)

In this post we’ve seen the basics of exporting, importing and composition in MEF. We’ve also touched on the concept of contracts and parts, which we will delve further into the future.

In the next post we’ll cover the following

Providing / Accessing export metadata
Other ways to import and a deeper look at contracts
Providing custom exports

PS: This is not my normal style of posting. I am following in the lead of my mentor, guru and overall awesome guy Brad Abrams. Please feel free to give feedback on how I can improve. I am looking forward to taking this trip with you.

Code is attached.

MEF has landed in Silverlight 4. We come in the name of extensibility.

Glenn Block MSFT — Sun, 29 Nov 2009 11:10:00 GMT

http://www.flickr.com/photos/markusram/3641457838/

At PDC we announced that MEF has is now part of Silverlight 4.

This may sound like alien speak :-), so I’ll break it down for you. It means building maintainable/pluggable RIA apps just got a whole lot easier.

What is MEF?

The Managed Extensibility Framework (MEF) is a new library in Silverlight 4 for building RIAs that can be incrementally extended. With MEF you extend your apps in a declarative fashion and let MEF do the plumbing rather than writing all the plumbing code yourself.

It’s for you and your dev team – You can add and replace functionality to the system without having modify existing code. This means you and your QA team are happy because you don’t have to worry about introducing bugs into the existing code base.
It’s for your customers – MEF allows you to design applications and libraries that can be extended by third-parties after they have been deployed.
Always there, always ready – In Silverlight, MEF is ready to go whenever and wherever you need it. You don’t have to be an acrobat, or have a masters degree in complexity :-) You just do it.

Also available in Silverlight 3

MEF ships as part of Silverlight 4, but we’ve also made a Silverlight compatible version of MEF available on codeplex at MEF.Codeplex.com.

The Basics

THREE concepts, that’s all you need to know to get going.

Export to tell MEF you are providing a service or capability.
Import to tell MEF you need something.
Compose It – To tell MEF to go do it!

Below you can see the basics in action for creating a Hello MEF pluggable dashboard. First we create a pluggable widget which in this case is a simple user control.

Export it

To tell MEF it’s available, we simply throw an Export attribute on it and specify the contract (in this case we use a type) you want to export it as. We could choose any type that the Widget implements, but to keep it simple, lets just use UserControl. As you can see, we don’t have to derive from any special base types, or use any interfaces, you use whatever class you would like.

Import It - Import single

Notice our Widget has a Message property. Let’s let MEF provide that rather than hardcoding it as I want it to be customizable. To tell MEF we need it, we’ll just slap on an [Import] attribute. If we don’t specify a contract for the import, it will just derive the contract as being a string. However, being that we don’t want just ANY string, we want the Message, we can specify a specific contract such as “HelloMEF.Message”.

Next let’s create our message which our widget(s) will import. To do this we’ll create an export, but it will use a feature of MEF called a Field Export. This is because we don’t own System.String and can’t derive from it, instead we want to somehow create an instance of a string and export it as our message. With a Field Export we can do just that as can be seen below. If our needs are beyond simply setting a value which we can do in a field, MEF also supports property exports.

Import It – Import many

Lastly we need our host app to discover the extensions. To do that we’ll do two things. First, we will create a public collection of type UserControl. Next we’ll add an ImportMany attribute, telling MEF that our MainPage needs all exports of UserControl to be injected into it.

Compose It – Satisfy imports

Next we need to somehow tell MEF to go do some work and give it to us. Doing this is very easy, we just drop into the constructor of our MainPage and call the SatisfyImports method. Once we do, our Widgets collection will be loaded up with all available widgets.

Now we can simply loop through that collection and show the widgets, in this case by adding them to an Items control.

We’ve just seen the core essentials of MEF in SL4, that’s all it takes to get going! Our dashboard works, but it’s pretty simplistic. This is just the beginning of what is possible with MEF, we’ve literally only scratched the surface, however even with this small set of tools I’ve just given you, you can accomplish a lot! In future posts (on this blog or others :-) ) and in our Silverlight documentation you’ll see more about what’s possible. I covered some of this in my talk including lazy instantiation, export metadata, custom exports, dynamic recomposition, and application partitioning.

PDC talk

At PDC, I had the pleasure of delivering a talk on building extensible RIAs which is now available online here. As a highlight I was joined by Ariel Ben-Horesh of Sela, and Jackson Harper of the Moonlight team at Novell.

Check out my PDC talk: Building Extensible Rich Internet Applications with the Managed Extensibility Framework. In addition to seeing MEF in action, you’ll see some work around integrating MEF with Prism and even using MEF on Moonlight, the open source Silverlight implementation. More on this in a future post!

You’ll also see how to surgically add extensibility to an existing application, and how to dynamically partition applications such that functionality is delivered on demand at runtime!

Can’t wait, want more?

Check out the attached demos (Yes code!) from that talk. (Requires Silverlight 4)
Head over to MEF.Codeplex.com and download MEF Preview 8 which contains several Silverlight samples including an extensible DataGrid. These samples work on SL3 or on SL4.
Check out Brad Abrams series on MEF and Silverlight
Check out Erik Mork’s screencast on MEF and Silverlight.
Check out these podcasts on MEF and Silverlight

Also watch for Jesse Liberty and Tim Heuer’s blogs as you’ll likely see some MEF/Silverlight content there VERY soon. ;-)

Building extensible RIAs at PDC

Glenn Block MSFT — Mon, 16 Nov 2009 18:14:29 GMT

This week I’ll be attending PDC in Los Angeles speaking about using MEF in Silverlight.

Building Extensible Rich Internet Applications with the Managed Extensibility Framework

In Hall F on Thursday at 11:30 AM

Learn how the Microsoft .NET Framework 4 introduces the Managed Extensibility Framework (MEF) for building customizable applications that can easily be extended by third parties. Whether you are building an extensible data grid, a custom rules engine, a pluggable editor, or a composite application such as a pluggable CRM system, you want to learn about MEF. Hear how to use MEF to decouple your applications into more maintainable and testable pieces, and partition your application into dynamically deployable chunks that download on-demand.

If you haven’t heard, MEF is available in Silverlight similar to it’s availability on the desktop. But what does it mean to build an extensible app in Silverlight? Yes it’s technically possible, but why should you care? In this talk we’ll explore different application scenarios for when MEF is a good fit. We’ll also explore some of the SL specific features we’ve introduced in order to enrich the MEF experience.

Hope to see you there!

Glenn

Should I use MEF with an IoC container? - Part 1

Glenn Block MSFT — Sun, 01 Nov 2009 10:31:00 GMT

In my post "Should I use MEF for my IoC needs" we took a look at the question of whether or not it is appropriate to use MEF instead of a traditional IoC container. In this post we'll discuss the question of whether or not you should use both an IoC container and MEF in the same application.

MEF and IoC container concerns

As we've mentioned in the past, MEF's primary design in V1 is around open-systems whose components (parts) are dynamically discovered at runtime. IoC containers on the other hand are primarily designed for decoupling a closed (fixed) set of application components in order to improve the maintainability of the system by the engineering team. In other words each is addressing a specific set of concerns. So if that is the case then is it plausable to use both in an application? The answer is Yes. Not only that, but we specifically designed MEF with the idea of integration with other containers in mind. Below will explore one of the key-scenarios for doing this.

Enabling third-party extensibility in an IoC container-dependent application.

You have an existing customer management system that uses an IoC container such as Castle Windsor which you use in order to promote separation-of-concens and testability. The application leverages advanced Windsor facilities for integrating with NHibernate and for applying cross-cutting-concerns (AOP) such as logging, etc. The loosely coupled design of the system has proven to be greatly beneficial and has minimized the friction for developing and deploying the system through several releases.

At some point requests start pouring in from customers want to create their own extensions in order to customize the application in their specific environments. Additionally several ISVs express interest in providing third-party value-adds such as telephony integration, and scheduling. You determine that adding a third-party extensibility model to the application makes sense in order to address this opportunity. Through your research you come across MEF and realize that it provides the infrastructure you need for extensibility. However it does so in a manner that overlaps with many of the functions that Windsor is providing. What to do? Let's explore various options.

a. Migrate the existing code to use MEF and remove the IoC container completely.

One option is to consider ripping out Castle and just using MEF. Technically this sounds reasonable, however after investigation it is not feasible. There are literally thousands of components that are currently registered in the Windsor container. Moving these to MEF involves modfying all of these existing classes in order to make them discoverable by MEF, not to mention refactoring all the places in the application where the container is accessed. Because the changes are so widespread, the likelihood of introducing breakages / bugs in the system is very high. Additionally there are the various Castle facilities such as Dynamic Proxy, and NHibernate integration which MEF does not yet support, which will have to authored by the team. The cost / risk of such changes is too prohibitive, not to mention that it seems like it should be unnecessary.

b. Implement a custom extensibility mechanism built on top of the IoC container?

Another option is to author a home-grown solution. This can be a viable option depending on the needs, and the willingness to author your own solution. For simple cases you can easily facade an extensibility mechanism on top of an IoC. Once you start getting into more advanced features like lazy instantiation, metadata, recomposition and stable composition, you are in for quite a bit of work.

c. Have both the IoC and MEF both present in the same application?

The final option I want to discuss (and the one I recommend for these situations) is to use both. Use the IoC container for addressing internal application decoupling needs, and use MEF for third-party extensibiltiy needs, that is the IoC container for IoCish things and the MEF container for MEFfish things :-)

This path is appealing for several reasons.

It works with existing codebases whether they be applications or frameworks. it does not require any significant rewrite.
It allows leveraging the strengths of each container for the things it does best. For example leveraging MEF's metadata model for discriminating between different extensions vs the dynamic proxy support in Castle.

However, there are several caveats of this approach.

It raises questions such as:
- Which component (part) should live in which container?
- Who owns the lifetime?
- Can a MEF part access services coming from the IoC? How?
- Can the IoC access exports coming from MEF? How?
It increases complexity in that now there are components living in mulitple places.
It increases the potential points of failuire within the application.

All of these issues are managable. In my next post we'll see how.