WinRT support

Topics: Getting Started
Jun 5, 2012 at 12:54 AM


I saw WinRT on the home page as supported framework but Caliburn doesn't seem to work with it.

What is the current status regarding WinRT? 


Jun 5, 2012 at 4:38 AM

I second the question. The v1.3.2 source has WinRT source, but it doesn't build ("'Windows.UI.Core.CoreDispatcher' does not contain a definition for 'Invoke' and no extension method 'Invoke' accepting a first argument of type 'Windows.UI.Core.CoreDispatcher' could be found (are you missing a using directive or an assembly reference?)")

I'm really looking forward to Caliburn.Micro goodness for WinRT.

Jun 6, 2012 at 2:59 PM

The WinRT RC has removed the Invoke-method from Windows.UI.Core.CoreDispatcher. I'll try to find the alternative method. Happily that seems to be the only breaking change with this release.

Jun 6, 2012 at 3:17 PM

It seems that the following code works:

            var dispatcher = Window.Current.Dispatcher;

            SetUIThreadMarshaller(action => {
                if (dispatcher.HasThreadAccess)
                else dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => action());

Jun 6, 2012 at 3:17 PM

I was able to "make it work" by using the new Async/Await functionality. It SHOULD be an easy fix...

Jun 6, 2012 at 3:21 PM

@miksu: I fear that your code is not synchronus, as the original CM code is. You probably need a Wait() call at the end of the RunAsync method.

Jun 6, 2012 at 4:02 PM
BladeWise wrote:

@miksu: I fear that your code is not synchronus, as the original CM code is. You probably need a Wait() call at the end of the RunAsync method.

Actually I've never before realized that Execute.OnUIThread is synchronous, meaning it uses Invoke rather than BeginInvoke. Is that by design? 

Jun 6, 2012 at 4:08 PM

Yes it is, the purpose of Execute.OnUIThread is to ensure that some code that requires to be executed on the UI thread is dispatched, while calling code awaits for the execution to complete. If it was asynchronous, the developer would be responsible to provide proper synchronization between the calling thread (potentially a worker thread) and the UI thread.

Jun 6, 2012 at 4:13 PM

The following change seems to work for me:

var dispatcher = Window.Current.Dispatcher;

SetUIThreadMarshaller(async action => {
                if (dispatcher.HasThreadAccess)
                else await dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => action());
Jun 6, 2012 at 5:06 PM

Are you sure that the dispatched action is synchronous with the calling thread?

I have not tried the async framework yet but I think that unless the Execute.OnUIThread waits for the thread marshaller delegate, the behavior is equivalent to the BeginInvoke call. The await in the lambda will cause the caller to go on, while it should wait (and not await) for the callee to complete. Again, this is not based on some tests, just on my understanding of the new features of the async framework... I could be wrong, tho...

Jun 6, 2012 at 5:47 PM

Hi - hope this isn't derailing the thread, but one other change between the Beta and RC of .NET for Metro style apps relates to the use of MEF. I'm not sure if it will affect existing Caliburn apps, but thought I'd mention it here since MEF is used extensively with Caliburn on other platforms.

Building a bootstrapper for the new MEF version is relatively straightforward, but the MEF team is here to help if there are any challenges. I've investigated what changes are required to make the default WPF template work with this package, the bootstrapper code seems like it will be identical for Metro style apps. I haven't verified anything more than that the app runs, so please forgive any obvious errors :).

First, the Microsoft.Composition NuGet package needs to be installed.

Then, some basic namespace changes to move from System.ComponentModel.Composition to System.Composition:

    using System;
    using System.Collections.Generic;
    using System.Composition;
    using System.Composition.Convention;
    using System.Composition.Hosting;
    using Caliburn.Micro;

Configuring the bootstrapper is a little simpler than the previous version. Some changes are required so that the window manager and event aggregator can be created by MEF rather than passed in as preexisting instances.

Instead of storing the container, we store an ExportFactory that creates new composition contexts. This is a guarantee against memory (reference) leaks: as some will know, MEF holds references to IDisposable parts. The changes between Beta and RC are driven partly by the need to make dealing with this more predictable. By creating a new composition context for each service lookup, we ensure that disposable, non-shared parts can be garbage collected along with the context object.

    public class AppBootstrapper : Bootstrapper<IShell>
        ExportFactory<CompositionContext> contextFactory;

        protected override void Configure()
            var defaultPartConventions = new ConventionBuilder();
            defaultPartConventions.ForTypesMatching(t => true)

            var container = new ContainerConfiguration()
                .WithParts(new[] { typeof(WindowManager), typeof(EventAggregator) }, defaultPartConventions)

            contextFactory = container.GetExport<ExportFactory<CompositionContext>>();

        private CompositionContext CreateCompositionContext()
            return contextFactory.CreateExport().Value;

The remaining changes just switch over from from the AttributedModelServices-style APIs to use the simple overloads of GetExport(), GetExports() and SatisfyImports(). These have the exact behaivor required by Caliburn by default, so the extra work required by the earlier version is eliminated.

        protected override object GetInstance(Type serviceType, string key)
            return CreateCompositionContext().GetExport(serviceType, key);

        protected override IEnumerable<object> GetAllInstances(Type serviceType)
            return CreateCompositionContext().GetExports(serviceType);

        protected override void BuildUp(object instance)

Finally, any parts that have to be shared need to be explicitly marked with the [Shared] attribute. More details on what we've done in this release are in the blog post above. Instructions on migrating from the Beta version of MEF for Metro style apps are on the MEF wiki.

Hope this helps, we'd love to hear about your experiences, and please get in touch with any questions.

All the best!

Nick (from the MEF team)

Jun 8, 2012 at 3:23 AM


I am interested in how you were able to implement Bootstrapper in WinRT. I'm stumped because I can't seem to locate the base Bootstrapper<T> class in Caliburn.Micro. I've begun a new thread on that topic at if you'd care to weigh in.

--- Jim ---

Jun 8, 2012 at 3:14 PM

Hi Jim - my investigation was with the WPF project type, so no ideas I'm afraid.


Jun 8, 2012 at 7:44 PM

So I'm confused, Caliburn does or does not support WinRT metro apps?

Jun 8, 2012 at 8:13 PM

INCP + EventAggregator + IOC works. Meaning Screen / Conductor etc. "high-level" stuff doesn't work yet, but the "low-level" classes like PropertyChangedBase and BindableCollection are good to go.

Jun 12, 2012 at 8:15 AM
JimboM wrote:


I am interested in how you were able to implement Bootstrapper in WinRT. I'm stumped because I can't seem to locate the base Bootstrapper<T> class in Caliburn.Micro. I've begun a new thread on that topic at if you'd care to weigh in.

--- Jim ---

Do u have resolved the problem yet?

Jul 12, 2012 at 12:56 PM


I'd like to use Caliburn.Micro as my basic MVVM framework for Metro application which I plan to create in the nearest future. But from the posts I already read I see that only part of functionalities of this great framework have already been ported. Does someone know the date, in which we could use all features known from previous versions of Caliburn.Micro (eg. those ones mentioned by miksu in post from Jun 8)?

Jul 12, 2012 at 2:45 PM

Good luck with that. While Caliburn.Micro seems to be a great way to develop WPF and Silverlight applications, there has been ZERO communication from the author regarding WinRT development using CM. The only conclusion I can come to is "false advertising"...the Caliburn.Micro codeplex page cheerfully implies it supports WinRT development. Unfortuately the bottom line is that there is NO useful support for WinRT in CM, there hasn't been any since the Win8 Release Preview, and the author doesn't seem too concerned about fixing that anytime soon. Any fixes that have been done are user contributed.

I am currently using MVVM Light, as the author (Laurent Bugnion) has made great efforts to keep his product up to date with the real-world bits we're running on.

I would like to suggest that the author of Caliburn.Micro needs to remove any/all references to WinRT from this codeplex project ASAP: until CM really TRULY supports WinRT, he's just polluting search engine results with a claim that hasn't even been attempted.

Jul 15, 2012 at 2:37 AM

Look, it's simple. I've been working 80 hour weeks for months and haven't had time to work on doing a complete port. I ported the functional equivalent of MVVM Light. That includes: INPC, Design time checking, UI thread marshaling, event aggregator and IoC.  It's an open source project, so anyone could have done work to port any or all of the rest of it, but no one has. Everyone is just waiting on me. Well, you are going to have to wait because there aren't enough hours in the day for *me* to work on it. I will get to it. But, right now, I've got to feed my family. When things slow down for me, then I'll look back into it (assuming it *can* be fully ported...preliminary research indicates large sections may not be possible to port due to *tons* of missing functionality in that my fault?... or is it Microsoft's problem for ignoring existing communities?). Normally these issues would have been resolved during the course of my normal consulting because often companies pay me to consult and I fix or extend the framework as part of the project...and then the community benefits. But, no one has ever contacted me about WinRT work. No one. So, I can't justify doing the work until I have freetime again. That's really not going to be until September at the earliest.

Jul 16, 2012 at 8:59 PM

It's all good Rob, a lot of people are just too entitled when it comes to open source projects. Thanks for all your hard work on the project.

Jul 16, 2012 at 10:11 PM

Finally the author speaks. Would it have been so difficult to have posted a status update on this site indicating the situation? Quality open source code comes with a developer's commitment to communication. Without even simple communication on the current status (and tons of BROKEN documentation and samples remaining on this site), this project is DEAD. For those of us who did contribute to getting the little parts of this working (see above in this thread), I salute you. For the author, good luck with the project. I moved on.

Jul 16, 2012 at 11:27 PM

Pre-existing documentation regarding the Status of WinRT can be found in many places simply by doing a search. Here's what I found in less than 5 minutes:

Forum Posts on Status

Related Blog Posts

Release Notes

Change Sets

The Source Code Itself

As far as I know, the samples and documentation are all correct. I try to fix those whenever someone raises a specific issue.