This second post of the “WPF must have” series deals with Resharper and its ability to find binding errors in XAML.
Resharper is a well known Visual Studio plugin used by many.NET developers. It’s a great productivity tool developed by Jetbrains. Even if Resharper (abbreviated in R#) handles javascript and other languages such as VB.NET, I would say that R# is a must when it comes to C#. In addition, we will see in this post that it is also really adapted to XAML editing.
If you have followed my previous post regarding WPF and MVVM, you saw that the ViewModels (VMs), consumed by the Views (composed essentially of XAML code), are proposed by ViewModel locators, for top level VM, or by ViewModel properties. In all cases, we always manipulate the VMs through C# interfaces. This has two major advantages, the first one being the ability to work with design time data (see the first post of the series) and, the second one, to leverage unit testing (this will be the topic of the third post of the series). In addition, specifying the DataContext (i.e. the ViewModel) of a given view through an interface is particularly well adapted to R# usage in XAML.
Let us have a look at the MainWindow.xaml designer and its XAML source taken from my usual sample application DesignableMVVMSample. The vertical bar next to the XAML code is the R#’s warning/error notification zone. My recommendation is to keep the error count to zero so that the XAML file status stays always to full green (no warning, no error).
The extremely cool feature is that you will benefit from an extension of Visual Studio’s intellisense provided by R#. The interface IMainViewModel exposes a property called AvailablePersons. See in the picture below: all the properties of the ViewModel’s interface (AvailablePersons and BooksWrittenTabViewModel) are now proposed in bold, to distinguish them from the UserControl’s Dependency Properties.
In addition, this works very well with the strongly typed translation mechanism that I presented in this previous post. Remark that all available translations are now proposed by R# and if you try to use a non translated string you will get a binding error.
As usual with Resharper options, you can disable them at several level: team level, solution level etc. , but more importantly, you can ignore them just once. Indeed, sometimes R# gets wrong and you may want to disable the warning/error. When you click the error you have the possibility to do this by adding the following comment in XAML. . Obviously, this should be exceptional, if you use this too often there is something suspicious in your code.
Let us finish by one tip. R# can detect binding error with “sub datacontext”, however, within a DataTemplate, Resharper is not always able to recognize well the DataContext type and will raise binding errors where there are none. The trick to avoid such errors is to “force” the DataType in the DataTemplate, see the sample below.
When developing our product KAssistant, a legal management software fully integrated within MSOutlook, my associate Grégoire who is not a C# expert, was handling most of the work regarding the design and the views in XAML. Early binding errors detected by Resharper was of a great help and saved us a lot of precious time to focus more on the features of our product.