Validate data binding in XAML in compile time

Question

I’m working on WPF based application. Environment is VS2008 SP1 with .NET 3.5 SP 1. In our development we are using MVVM pattern widely.

I.e. application developers write Models and ViewModels (C#), then UI developers will write Views using WPF Binding (XAML). Application developers also write unit tests on top of ViewModels. We are using Continuous Integration methodology and we are diond build and executing unit test on each modification

The problem is a lack of process or tools of data binding correctness validation in XAML. For example:

1. App developer writes property NmberOfApples and unit tests to check its correct behavior
2. UI developer creates user control and bind it to the property
3. App developer finds that property has misspelling and fix its name to NumberOfApples
4. It would be compilation time errors in any C# code uses NmberOfApples property, and such errors will be easy to catch (Continuous Integration)
5. Data binding in XAML files are not going to be validated and it will be run time error

My question will be “Is there any tool or methodology that help us validate data binding correctness in XAML in compile time?”

Answer 1

There are a number of arguably good scenarios where this behavior is actually desired. In any case, it is by design that bindings swallow errors and is the reason you are going to have trouble finding anything that will help you with this.

The best thing I've seen is an exception validation handler that will display binding errors: http://msdn.microsoft.com/en-us/library/system.windows.controls.exceptionvalidationrule.aspx

The argument for this is views and ViewModels are meant to be decoupled to the point where a View could be used for multiple ViewModels. It also aids in the "Bendability" of the views so that theoretically designer types can style a view without running into a bunch of errors while they are doing it. I realize this might not fit with your process, but that's the story.

Answer 2

I agree with the previous answer. This is "by design" and there is no way to check it at compile time.

I've also found it a pain.

The best and only way I found is to check the Visual Studio debug output at runtime. Any binding error will be printed as soon as you open the window containing it.

I agree if you think it's a crappy and unreliable method, but it should work if you don't have a huge number of windows. You could create a semi-formal test practice where once in a while you open any window looking specifically for binding errors.

Answer 3

Currently we are using Caliburn and unit tests in the way explained in this article Testing Bindings In WPF. The drawback of this solution, UI developer writes code that has only meaning to validate bindings and can be omitted if MS (or somebody) would write XAML validation compiler.

Answer 4

A solution to your problem is discussed in this article.

The basic idea is to create a ViewModel MetaData set of static(c#) classes that hold the string value of the properties of your ViewModel classes which you can then use in your xaml. The article explains how to use T4 text generation to create these static metadata classes. You could use any code generation tool of your preference.

so your VM has the following:

namespace Mine
{
  public class MyViewModel
  {
    public int MyInt {get;set;}
   public string MyString {get;set;}  
  }
}

And you code generation would create this:

namespace Mine.MetaData
{
  public static class MyViewModelMetaData
  {
    public const string MyInt = "MyInt";
    public const string MyString = "MyString";
  }
}

and then in your xaml you would add the namespace to your xaml and bind your controls to the metadata class

<TextBox Text="{Binding Path={x:Static Metadata:MyViewModelMetadata.MyInt}}"/>

If you use an add-in like resharper then it will give you intellisense on the properties of the static class and also because you are referencing an exact property in a static class, when the static class gets regenerated your xaml should not compile.

It's pretty slick, I think it's awesome and it has the chance of keeping most people sane, but your mileage may vary. :)

EDIT:

By the way, I don't buy the "ViewModels are tightly coupled to the Views". In my opinion Views are inextricably bound to their ViewModels, but it should only be one way. ViewModels should be completely independent of any view implementation. It's like the ViewModel is the interface and the View is the concrete implemented class. So for this reason I don't put in any WPF-specific properties(e.g. Visibility enumeration) into my ViewModel because that binds me to use WPF for eternity(which isn't really a bad thing :) ), but it compromises maintenance.