Recently I’ve been seeing a lot of problems with the XAML Designer in Visual Studio 2019.
It’s always been a little bit iffy, the error “Invalid Markup”, “Check the error list for more information.”, “UserControl is not supported in a Windows Presentation Foundation (WPF) project.” has been cropping up fairly regularly for quite a few months now:
Sometimes the error says “Window is not supported in a Windows Presentation Foundation (WPF) project.” – which is equally as silly in a Windows application, but the usual course of closing Visual Studio and re-opening it makes the error go away.
There is a better way…
Recently I discovered that the Visual Studio XAML Designer runs as a separate process to Visual Studio 2019 (Devenv.exe). This is likely an attempt by Microsoft to overcome the limitations of Devenv.exe still being a 32 bit application with little chance of ever being ported to 64 bit by splitting out areas of functionality into their own processes. Yes it looks like the XAML designer is still only 32 bit, but it means it gets a stab at its own 4Gb of RAM instead of having to share it with the main Visual Studio Process.
Anyway, what it means is that if you come across XAML Designer weirdness as mentioned above, opening Task Manager and killing the Microsoft Visual Studio XAML Designer (32 bit) process:
will give you the following:
Click on “Click here to reload the designer” and normal service wil be resumed.
Saves having to close and re-open Visual Studio – which if you’re like me and have 72 projects in your solution can take some time.
But wait, there’s more…
In additional to the above piffling niggle, I hit a more major problem with the XAML designer the other day when one of the WPF views (a User Control) I was working on refused to load into the designer and hung Visual Studio completely. The entire IDE would lock up, turn light grey when clicked (presumably as all the blood ran out of it) and it would have to be killed via Task Manager.
Other WPF views (user controls and Windows) all loaded fine in the XAML designer, just this particular one would crash VS when loaded.
As you can imagine, troubleshooting this was particularly painful. The usercontrol in question made use of a number of 3rd party controls which rely on XML theming from external DLLs. I found that if I commented out all of the 3rd party themes from being loaded into the application resource dictionary, the XAML designer would no longer crash. The usercontrol wouldn’t display anything as all its theming had been removed. But VS didn’t crash.
One by one I re-instated the theme DLLs until the XAML designer crashed and eventually I found one reference in the resource dictionary that caused the crash… or so I thought…
Red Herrings and other political fish…
I thought to myself, shall I raise a bug on the Microsoft Developer Community Forums? “Don’t be stupid” I replied – why face the humiliation of taking time to report a bug to Microsoft only to have an AI bot close the bug in a couple of months due to a lack of interest.
As it happens I did raise a bug, and this time Microsoft participated with it (yes they required a ton of extra info) but they did engage this time. Anyway I digress, as I actually found the resolution without their help as follows:
Remember I mentioned earlier about killing the XAML Designer process in Task manager, and how it is a cure for all know evils including warts, pox and ugly babies? I decided to try this approach on the hung usercontrol.
I loaded my solution in VS, and viewed the designer for the iffy view.
Right on cue Visual Studio hung, so I went to Task Manager and killed the XAML Designer process, and this time I got the following:
This time I clicked “Click here to enable running project code and reload the designer“, and Bingo! the failed view, the one that had been crashing Visual Studio for the past 3 days, the one that had me doubting my sanity and coding abilities, it loaded fine, and has been doing so ever since.
Problems, problems everywhere…
I might add that the problem first occurred in VS 2019 V16.9.3.
I also have a side install of V16.9.0 and V16.9.10 Preview, because every time Microsoft release an update to Visual Studio they break something, or some times many things. Having several versions on the go means that when Microsoft break Visual Studio I can just load my solution in a previous version that has different bugs that don’t affect me so much.
I had the same problem with all three versions of Visual Studio, but when I fixed the problem in one of them, it was fixed in all three.
So this suggests that whatever the corruption was in Visual Studio, it was common to all side by side installations.
Some say there is a folder in your Windows user profile that serves as a shadow cache for the XAML Designer. Some say that this folder can become corrupted. I have to say I am inclined to believe them. But armed with the power to kill the XAML Designer process whenever it gets out of control, I don’t feel the need to venture any further into undocumented territory.
