.NET & Funky Fresh



  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper

In the last part we discussed the most basic configuration for Caliburn.Micro and demonstrated a couple of simple features related to Actions and Conventions. In this part, I would like to explore the Bootstrapper class a little more. Let’s begin by configuring our application to use an IoC container. We’ll use MEF for this example, but Caliburn.Micro will work well with any container. First, go ahead and grab the code from Part 1. We are going to use that as our starting point. Add two additional references: System.ComponentModel.Composition and System.ComponentModel.Composition.Initialization. Those are the assemblies that contain MEF’s functionality.* Now, let’s create a new Bootstrapper called MefBootstrapper. Use the following code:


using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
using System.Linq;

public class MefBootstrapper : Bootstrapper<IShell>
    private CompositionContainer container;

    protected override void Configure()
        container = CompositionHost.Initialize(
            new AggregateCatalog(
                AssemblySource.Instance.Select(x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()

        var batch = new CompositionBatch();

        batch.AddExportedValue<IWindowManager>(new WindowManager());
        batch.AddExportedValue<IEventAggregator>(new EventAggregator());


    protected override object GetInstance(Type serviceType, string key)
        string contract = string.IsNullOrEmpty(key) ? AttributedModelServices.GetContractName(serviceType) : key;
        var exports = container.GetExportedValues<object>(contract);

        if (exports.Count() > 0)
            return exports.First();

        throw new Exception(string.Format("Could not locate any instances of contract {0}.", contract));

    protected override IEnumerable<object> GetAllInstances(Type serviceType)
        return container.GetExportedValues<object>(AttributedModelServices.GetContractName(serviceType));

    protected override void BuildUp(object instance)


That’s all the code to integrate MEF.  First, we override the Configure method of the Bootstrapper class. This gives us an opportunity to set up our IoC container as well as perform any other framework configuration we may want to do, such as customizing conventions. In this case, I’m taking advantage of Silverlight’s CompositionHost to setup the CompositionContainer. You can just instantiate the container directly if you are working with .NET. Then, I’m creating an AggregateCatalog and populating it with AssemblyCatalogs; one for each Assembly in AssemblySource.Instance. So, what is AssemblySoure.Instance? This is the place that Caliburn.Micro looks for Views. You can add assemblies to this at any time during your application to make them available to the framework, but there is also a special place to do it in the Bootstrapper. Simply override SelectAssemblies like this:


protected override IEnumerable<Assembly> SelectAssemblies()
    return new[] {


All you have to do is return a list of searchable assemblies. By default, the base class returns the assembly that your Application exists in. So, if all your views are in the same assembly as your application, you don’t even need to worry about this. If you have multiple referenced assemblies that contain views, this is an extension point you need to remember. Also, if you are dynamically loading modules, you’ll need to make sure they get registered with your IoC container and the AssemblySoure.Instance when they are loaded.

After creating the container and providing it with the catalogs, I make sure to add a few Caliburn.Micro-specific services. The framework provides default implementations of both IWindowManager and IEventAggregator. Those are pieces that I’m likely to take dependencies on elsewhere, so I want them to be available for injection. I also register the container with itself (just a personal preference).

After we configure the container, we need to tell Caliburn.Micro how to use it.  That is the purpose of the three overrides that follow. “GetInstance” and “GetAllInstances” are required by the framework. “BuildUp” is optionally used to supply property dependencies to instances of IResult that are executed by the framework.


Word to the Wise

While Caliburn.Micro does provide ServiceLocator functionality through the Bootstrapper’s overrides and the IoC class, you should avoid using this directly in your application code. ServiceLocator is considered by many to be an anti-pattern. Pulling from a container tends to obscure the intent of the dependent code and can make testing more complicated. In future articles I will demonstrate at least one scenario where you may be tempted to access the ServiceLocator from a ViewModel. I’ll also demonstrate some solutions.**


Besides what is shown above, there are some other notable methods on the Bootstrapper. You can override OnStartup and OnExit to execute code when the application starts or shuts down respectively and OnUnhandledException to cleanup after any exception that wasn’t specifically handled by your application code.  The last override, DisplayRootView, is unique. Let’s look at how it is implemented in Bootstrapper<TRootModel>


protected override void DisplayRootView() 
    var viewModel = IoC.Get<TRootModel>();
    var view = ViewLocator.LocateForModel(viewModel, null, null);
    ViewModelBinder.Bind(viewModel, view, null);

    var activator = viewModel as IActivate;
    if (activator != null)

    Application.Current.RootVisual = view;
    new WindowManager().Show(viewModel);


The Silverlight version of this method resolves your root VM from the container, locates the view for it and binds the two together. It then makes sure to “activate” the VM if it implements the appropriate interface. The WPF version does the same thing by using the WindowManager class, more or less. DisplayRootView is basically a convenience implementation for model-first development. If you don’t like it, perhaps because you prefer view-first MVVM, then this is the method you want to override to change that behavior.

Now that you understand all about the Bootstrapper, let’s get our sample working. We need to add the IShell interface. In our case, it’s just a marker interface. But, in a real application, you would  have some significant shell-related functionality baked into this contract. Here’s the code:


public interface IShell


Now, we need to implement the interface and decorate our ShellViewModel with the appropriate MEF attributes:


public class ShellViewModel : PropertyChangedBase, IShell
   ...implementation is same as before...


That’s it! Your up and running with your bootstrapper configured for MEF.


*If you are using .NET, you will only need to reference System.ComponentModel.Composition.

**I’m quite guilty of this myself, but I’m trying to be more conscious of it.  I’m also excited to see that modern IoC containers as well as Caliburn.Micro provide some very nice ways to avoid this situation.

Posted 07-08-2010 8:28 PM by Rob Eisenberg



dob wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 5:00 AM

there is no DisplayRootView but the code looks similar to the override of OnStartUp in Caliburn.Micro although the conditional compilation looks diff from what I got from codeplex

jose wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 6:07 AM


Very interesting stuff! One question, does Caliburn Micro work with the .NET 4.0 Client Profile or does it need the full framework?

Sean Kearon wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 6:15 AM

Great article Rob.  I'm really enjoying the series and being able to take a look at Caliburn.Micro.  Keep 'em coming...

grahamR wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 6:45 AM

Very interesting work here. The framework looks amazing.

However, I've not been able to get the exampe above to work. As already pointed out, there is no DisplayRootView to override. I guess because of that there are no instances of ShellViewModel.

Rob Eisenberg wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 8:41 AM

@dod and @grahamR

Please make sure you have the latest source code. I added this DisplayRootVisual as part of a bug fix yesterday :)


I haven't tested this with the Client Profile explicitly, but I can't think of a reason why it wouldn't work.

grahamR wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-09-2010 12:08 PM

Got the framework update. Very cool indeed.

Sidenote: If you forget to add the Export to your ShellViewModel, the framework reports that there are no instances of the ShellViewModel.

Looking forward to the rest of the series.

Ron Larvick wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-10-2010 1:43 AM


Excellent, excellent stuff.  Do you plan on putting up any kind of mock business application to show how to build something like that with your Caliburn.Microsoft framework?  Or should be just refer to your sample for your MVVM talk?

Vadim Kaantorov wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-12-2010 5:09 PM

Thanks for the bits!

Just curious, why did you choose creating a static IoC class instead of passing the reference to the container? For the sake of simplicity?

Anyway, there're only few places where IoC is touched...

Vadim Kantorov wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 07-15-2010 8:38 PM

Are you going to post the unit-tests you might already have for the framework?

David Esposito wrote re: Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper
on 09-23-2010 4:34 PM

For people following along from the 1st part, you might want to remind them to update their App.xaml file to change the class of the boot strapper:


                   <local:MefBootstrapper x:Key="bootstrapper" />


About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)