This project is read-only.

Using SilverlightCairngorm

Mar 24, 2009 at 9:00 PM
Hi -- I'm successfully using SilverlightCairngorm in WPF, however I had to change some things. For example, changing RootVisual to MainWindow. I also had to remove the thread-safe stuff otherwise NotifyPropertyChanged would always fail.

There is probably a better way to make it work in WPF. It would be cool if this were officially supported.
Mar 24, 2009 at 10:52 PM
It's interesting to see the usage of Silverlight Cairngorm expands to WPF, since Prism ( is the "official" framework for WPF on desktop, I never thought there is a room to use Cairngorm in WPF applications.

Before we get into the details, is it OK share some high level thoughts? I'd like to understand better what's the primary motivation to use Cairngorm in WPF apps. Is its lightweight, simplicity and easy to use? Any other big reasons? Despite the complexicity and difficulty to use of Prism, it offers something more than Cairngorm does, like Bootstraper, Shell, IoC, Logger, Region, etc., what's your opinion on those features in a framework?

Now, let's talk about the specifics: changing  App.Current.RootVisual to App.Current.MainWindow is definitely needed, since Silverlight uses this.RootVisual = new Page() while WPF start up event handler set to StartupUri="Page.xaml";

However, I don't think the thread-safe code need to be removed, because a WPF desktop application is more likely to have worker threads processing data than a Silverlight web application, thread-safe feature is more important in desktop applications, the "framework" should provide the support. What exact problem you ran into? I think the key is to get the correct Dispatcher instance, then the thread-safe code logic should still apply.

Mar 24, 2009 at 11:00 PM
Well, Prism is the official framework for Silverlight too, and we use CairngormSilverlight there as well. :) I am evaluating Prism for another Silverlight project, but the learning curve there is much greater than for Cairngorm, and the benefits of Prism are not really worthwhile on smaller, single-developer projects.

I am using Cairngorm in Silverlight because I was using it in Flex previously. Before SilverlightCairngorm, I had rolled my own Cairngorm port, but yours is better.

I am now using it in WPF because, in this case, I am making a WPF version of a Silverlight application, and am able to reuse all of my SilverlightCairngorm Events, Commands and ValueObjects.

I'm not totally sure what the threading issue was. It's quite possible that it's because I'm using remote debugging on a device (a MS Surface) other than the one I'm developing on. I wonder if SilverlightCairngorm running in Silverlight has the same issue? I've never tried to remote debug Silverlight.
Mar 25, 2009 at 8:28 PM
Thanks for sharing ideas. Now Silverlight 3 has offline out-of-browser capablity built-in in the runtime and it's fairly easy to turn on the offline installation by changing the deployment XML file, it renders some cases of porting Silverlight application to WPF unnecessary. I understand in certain situation, it's still valuable effort to have a WPF desktop app, say local resources access, security limits, etc.

I never used remote debugging for thread-safe code in Silverlight Cairngorm, but I did have some sample code to test when some logic running in a thread pool thread while needs to notify data binding events, it worked fine.

What happened after you chang CheckDispatcher() method from

currentDispatcher =




currentDispatcher =




CheckDispatcher()  is invoked when first time to run


string propertyName)


The code only needs to make sure to raise PropertyChanged event AFTER MainWindow is fully constructed.