What to do if you get a NullReferenceException in the XAML designer

I kept having problems when I opened a XAML file, in that the designer would show the following…

This makes it somewhat hard to design a view when you can’t see the design!

It turns out that when the XAML designer loads, it attempts to run code in your view model. There is some (questionable) justification for this, but overall, it’s a huge pain, and is one of the reasons why editing XAML files can be such a slow and tedious process.

However, there is a way to mitigate the problem. If you can identify which parts of your code are causing issues, you can add code to prevent them from running when you are in Visual Studio. First you need to add the following line to the top of your code file…

using System.Windows;

…then wrap the offending code in a check as follows…


private void DoSomethingThatCausesAnExceptionInTheXamlDesigner() {
  if (Application.Current is App) {
    SomeDumbCode();
    MoreDumbCode();
  }
}

Apart from the fab method name (who says my method names aren’t descriptive eh?), the “if” statement there prevents the code in the body of the method from running when in design mode.

Make sure you get the if statement the right way round. The expression above will be true when the code is running properly. If you want to detect when the code isn’t running, meaning that it’s being called by the XAML designer, then you would want to negate the expression…

if (!(Application.Current is App)) {
  //...

Note: You may be tempted to use IsInDesignMode in the “if” statement, as this was designed for the purpose. As far as I can see, there isn’t any difference to either approach for code running in the view model itself. The advantage of the code shown above is that it works absolutely anywhere, not just in a view model. If your view model calls code in other classes, and that code causes the exception, you can’t use IsInDesignMode. So, while this code is slightly longer, it means we have a consistent approach to this problem everywhere.

However

You may find that this still doesn’t fix the issue. If so, you need to pay more attention to the exception message. I’m not being rude, it took me about six months (no kidding) before I did this! I was working on a window, and naively assumed that the exception was being raised in the view model for that window. Looking more closely at the stack trace, it appeared that the exception was happening in a totally different view model, one that wasn’t referenced from this view, and one that hadn’t even been instantiated during my debugging that day!

Now if you re-read that last sentence carefully, it will reveal something quite worrying. It seems that Visual Studio is running code in view models that are completely unrelated from the one associated with the current view. Potentially it could be running code in every view model in your solution!

Can you say “Huh?

Yes, that’s pretty much what I thought!

The solution is simple, you just look at the stack trace and see which view model is causing the problem, and add the code shown above. Eventually you’ll run them all to ground.

It does make you wonder what Microsoft were thinking though. I guess that’s a topic for another day!

Be First to Comment

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.