I’ve recently been getting acquainted with C#, WPF, and the MVVM pattern. After a few months dealing with Javascript and Groovy, it has been a refreshing experience. Not having much background in C# or Windows, I’ve had to learn a lot.
In order to get off the ground quickly, I chose Laurent Bugnion’s MVVM Light framework to build a test project around. MVVM Light provides a nice framework upon which to base a MVVM application, with some handy facilities for messaging and commands.
As I built up my test project, I was quite happy with everything. I had previously started building a test WinForms application which downloaded files over the internet in parallel. I used this same idea to test out WPF. In short order, I had a worker thread system downloading files from different servers. Each thread was updating model properties which fired PropertyChanged events to update a view’s progress bars. All of this worked straight away, without any of the WinForms worries about only triggering updates from the UI thread.
My first real problem cropped up when I started rounding out my test suite. In a bunch of tests for a certain class, I was registering with the MVVM Light Messenger to verify a message was fired. I could run all of the tests in this class one-by-one, and they would pass. I could run all of them together in Visual Studio’s debug mode, and they would all pass. But when I ran them all in release mode, the last test in the list would fail with a “Non-static method requires a target” exception. Ugh.
With some extensive googling, I came across an issue report on the MVVM Light codeplex page: http://mvvmlight.codeplex.com/workitem/7579. Here, it is suggested that stale message listeners can cause the Messenger to send a message to an object that’s already been garbage collected. When I had registered for messages in my test code, I had inadvertently triggered this behavior.
In order to prevent this from happening, I added a call to Messenger.Default.Unregister<>(); in my test teardowns. My tests started running reliably. Huzzah!
The Messenger system in MVVM Light is pretty nice. It’s quite flexible, and provides a good way to loosely couple components. This behavior really tripped me up, though.
I’m acutally surprised reading your post. For someone with little C# and WPF experience, thus I’m assuming little .NET experience in general, you’ve had to learn quite a lot. I’m somewhat baffled that you’re already into MVVM patterns and debugging messagebuses. +1
I’ve been working intensely with .NET (mostly ASP.NET) the past three years and recently started my a WPF project myself. It amazed me how much what kind of learning curve WPF still posed to me, but then again, I might just be slow ;-). I started out with MVVM Light myself, wish you would’ve posted this two months earlier! I had so much trouble finding decent examples and documentation, I gave up after a while.
I’m now working with SimpleMVVM. The two are very similar, slightly different implementations here and there. Documentation and examples are also a bit of an issue with SimpleMVVM, but there’s just enough out there that I was actually able to get the job done. Also has a messagebus to send messages in a decoupled manner, it’s all pretty nice. Should you consider switching, give it a try. So far, I’ve only seen two downsides: 1) The MessageBus does not unittest very well, 2) Exceptions in code executed through the messagebus get ignored.
Oh well, my two cents :) Happy programming!