I found a good example of this in Chapter 5 of Professional Silverlight 2 for ASP.NET Developers by Jonathan Swift, Salvador Alvarez Patuel, Chris Barker and Dan Wahlin. As I describe it, and continue the discussion through this post, you’ll notice that the term “resource” is overloaded in Silverlight: There are resources in the normal .NET sense, backed by .resx files, and there are resources that are simply a dictionary of objects instantiated in XAML within a Resources element. Hopefully the usage will not be overly confusing.

In the localization example from the book, they created a resource file called LocalizedStrings.resx. Then they instantiated the automatically generated strongly typed class by including it in the Resources associated with a user control. Finally, they could then bind the Text property of a couple of TextBlock controls to a particular string from the resources:

<UserControl x:Class="SilverlightLocalizationExample.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Localized="clr-namespace:LocalizationExample.Resources">
 
    <UserControl.Resources>
        <Localized:LocalizedStrings x:Name="LocalizedStrings" />
    </UserControl.Resources>
 
    <StackPanel x:Name="LayoutRoot" Background="LightBlue">
 
        <TextBlock Text="{Binding TextBlock1,
            Source={StaticResource LocalizedStrings}}" />
 
        <TextBlock Text="{Binding TextBlock2,
            Source={StaticResource LocalizedStrings}}" />
 
    </StackPanel>
 
</UserControl>

You’ll want to be sure to use the PublicResXFileCodeGenerator custom tool to generate the code from the .resx file, otherwise the binding doesn’t work.

So what if you want to dynamically change languages, such as with a language drop-down?

The solution I came up with incorporates string resources into the view model. I was hesitant to do this at first because it felt funny having resources in the view model. Aren’t the strings purely a view component? Ultimately I decided that supplying the correct strings to the view based on language choice is a reasonable thing for the view model to do, and the resulting implementation and usage felt pretty good.

The base class for all view models simply has a Resources member:

public virtual object Resources
{
  get { return null; }
}

Each subclass then returns the appropriate object containing the resources:

public class MyViewModel : ViewModel
{
  private MyViewModelResources _resources;
 
  MyViewModel()
  {
    _resources = new MyViewModelResorces();
  }
 
  public override object Resources
  {
    get { return _resources; }
  }
 
  // ...
}

The class MyViewModelResources is the class generated from MyViewModelResources.resx. You might be saying, “Wait a minute. That class is basically static. What are you doing creating an instance of it?” Well, I don’t think there’s a way to bind to statics, so you need to have an actual instance around. Of course, the view will actually end up calling the static property (such as SubmitButtonText) when you include one in the binding path. Also, this isn’t any different from instantiating the resource class in XAML as the first example does.

Modifying the first example to use the view model (and setting the view model as the DataContext) makes the XAML look like this:

<UserControl x:Class="SilverlightLocalizationExample.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Localized="clr-namespace:LocalizationExample">
 
    <UserControl.Resources>
        <Localized:MyViewModel x:Name="ViewModel" />
    </UserControl.Resources>
 
    <StackPanel x:Name="LayoutRoot" Background="LightBlue" 
        DataContext="{StaticResource ViewModel}">
 
        <TextBlock Text="{Binding Resources.TextBlock1}" />
 
        <TextBlock Text="{Binding Resources.TextBlock2}" />
 
    </StackPanel>
 
</UserControl>

So what about the dynamic switching of languages at run time?

Since the “Resources” property is in the binding path, changing its value will update the bindings and the UI updates with the new strings. You just need to notify the view that the Resources property has changed. To make this easy, I created a helper method in the ViewModel base class, RaiseResourcesChanged, that effectively says, “Attention all view models, please update your views’ resources.” The message gets propagated to each view model instance by having a static ResourcesChanged event in the ViewModel base class that each ViewModel instance subscribes to at construction. When the event fires, the base class in turn raises the INotifyPropertyChanged.PropertyChanged event for the “Resources” property.

public class ViewModel : INotifyPropertyChanged
{
  private static event EventHandler ResourcesChanged;
 
  public ViewModel()
  {
    ResourcesChanged += ViewModel_ResourcesChanged;
  }
 
  protected void RaiseResourcesChanged()
  {
    var handler = ResourcesChanged;
    if (handler != null)
    {
      ResourcesChanged(this, EventArgs.Empty);
    }
  }
 
  void ViewModel_ResourcesChanged(object sender, EventArgs e)
  {
    RaisePropertyChanged("Resources");
  }
 
  // ...
}

Any single view model can then change the CurrentUICulture, call the helper method, and the UI updates automatically for all views:

Thread.CurrentThread.CurrentUICulture = newCulture;
RaiseResourcesChanged();

One of the goals of the model-view-view model pattern is to avoid code in the XAML code-behind files. Instead, the view model exposes what the UI needs and the UI consumes it through declarative data binding. Shawn Wildermuth’s MSDN Magazine article does a good job of explaining the basics of the pattern. The view model ends up having the logic that you’d really like to test.

The project structure looks like this:

• SilverlightApp – This project is the view, created with the Visual Studio Silverlight Application project template. There’s lots of XAML in here.
• SilverlightApp.Model – This project contains both the model and the view model. It is a Silverlight Class Library project, and the view project has a project reference to this. There’s no XAML in here.
• SilverlightApp.Model.Test – This project has the unit tests, and is a normal C# Unit Test project. It has a project reference to the model/view model project.

If you write up a simple unit test, it will compile, run, and pass.

Woohoo -- passing test.

Problem #1

Suppose your view model uses something from System.Core (such as the Action delegate). Now when you try to run your unit test, you get an error:

Test method SilverlightApp.Model.Test.UnitTest.TestMethod1 threw exception:  System.IO.FileNotFoundException: Could not load file or assembly ‘System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e’ or one of its dependencies. The system cannot find the file specified.

The problem is that the test project is referencing the .NET 3.5 System.Core assembly. You can fix that by referencing the Silverlight assembly instead. Remove the existing System and System.Core references, and add the ones in the Silverlight SDK (for example, C:\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies\). Now the test will pass again.

Problem #2

Now suppose that you want your view model to do something like use the IsolatedStorageSettings class. When you run your test, it will be broken again:

Test method SilverlightApp.Model.Test.UnitTest.TestMethod1 threw exception:  System.IO.FileNotFoundException: Could not load file or assembly ‘System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e’ or one of its dependencies. The system cannot find the file specified.

Well, that just looks like problem #1 again, so we’ll add the Silverlight System.Windows assembly as a reference. Hmm… still doesn’t work:

Test method SilverlightApp.Model.Test.UnitTest.TestMethod1 threw exception:  System.MissingMethodException: Method not found: ‘System.IO.IsolatedStorage.IsolatedStorageFile System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForSite()’.

According to the documentation, IsolatedStorageFile is in mscorlib.dll. Can I just add a reference to that? No; when you try you get an error:

A reference to ‘C:\Program Files (x86)\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies\mscorlib.dll’ could not be added. This component is automatically referenced by the project system and cannot be referenced directly.

It’s time to step back and think a little. Do we really want to have Silverlight isolated storage as part of our unit tests anyway? Probably not. Just like when you’re unit testing code that would access a database, you’d really rather mock the database so you can efficiently test just the unit in question. The same applies here, so you can create an interface to hide the concrete implementation. From there, it’s a matter of choosing the right implementation at the right time.

The view model can accept an ISettings in its constructor (or it can use a service locator or dependency injection). When creating a test instance, pass in a mock implementation. In the real application, you can use the isolated storage implementation.

So Far So Good

By using these two techniques (referencing Silverlight assemblies in the test project and adding a level of abstraction where needed), I’ve been able to effectively test my view models with the normal desktop tools. The tests all run as part of the continuous integration builds, just as you’d hope.

Maybe at some point I’ll run into something that just doesn’t work, but so far it’s working out just fine.