How To Debug XAML Design Views

When I work on a XAML view, I'll switch between the run-time view in the app, the XAML view, or the Design view, depending on what I'm trying to do at the moment. As I mentioned in my previous post, I'm a big fan of using the XAML Design views with sample data.

On occasion, something goes into the ditch, and I can't get the Design view to work. Since I lean towards the x:Bind syntax, a broken view might revert to showing the data bound property name instead of the sample data I've curated for it. Depending on how the app is configured, it might run great at run-time, but the design-time path is broken.

Visual Studio 2015 has a great debugger, and these steps show how to attach it to the Design view and uncover hidden exceptions that are not surfaced in the Design view.

How to Attach the Debugger to XAML Design Views

Step 1: Close all open files in Visual Studio 2015 and Blend.

Make sure both editors are launched and have the solution loaded; just make make sure all the files are closed. If Blend isn't launched yet, right-click the XAML file in the Solution Explorer, and select "Design In Blend".

Step 2: Open the code-behind file of the view and set a break point in the constructor. Let's ignore the flaw in the magic string that reaches into the resource dictionary in the following example for now and pretend it's a more complex error.

Pro-Tip: Select "x86" in the Solution Platforms drop down (in Visual Studio and Blend!) because this won't work when set to "Arm".

Step 3:  Attach the debugger to Blend

In Visual Studio 2015, select Debug > Attach To Process...

In the "Attach to Process" panel, verify the "Attach to" field is set to managed code.

Next, select "XDesProc.exe" at or near the bottom of the list. You should see two items with the same name, so hover over them and select the item with "Blend" in the tooltip. The other item is for Visual Studio 2015.

Step 4: Open the XAML design view in Blend

This action instantiates the view code-behind and results in the break point halting execution of your Design view experience.

Step 5: Observe the break point hit, and step through your code

From here you can observe the execution path taken by the Design view and hopefully deduce the cause for the Design view issue. Typically, you'll see the issue right away and realize your View or View Model was violating an obvious pattern. In my contrived case, I misspelled the key name of the resource dictionary item.

Attaching the Visual Studio 2015 debugger to Blend isn't always stable. There's lot of moving parts, so if you run into issues, you might restart both editors, clean and recompile, verify the Solution Platform configuration and other acts of superstition to jiggle your particular issue loose.