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 developer

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

If you install ReSharper, one of the (many) features you will get is "code inspection". One of the things this inspection will detect is cases where your binding does not resolve to a property on your data context. You can easily filter the "Inspection Results" window to only show these issues.

Note that you must explicitly state the type of your view model in your XAML resources for this to work.

Answer 3

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 4

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 5

It's been years since the original question was asked and answered but as I just checked, the solution might have gotten simpler since then. ReSharper seems to offer correct Intellisense without the need to generate the static classes mentioned in the accepted answer.

But I haven't witnessed the compile-time error as stated in the accepted answer. I even tried using [XamlCompilation(XamlCompilationOptions.Compile)] to no avail. Please stand me corrected if I am missing something.

Answer 6

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.