Or, "How to avoid crashing Visual Studio while working with XAML"
Our project may have problems. I don't know. What I do know is that, when you open a XAML file in Visual Studio, you are officially in The Danger Zone. And, after much careful thought and dozens of "unpredictable" crashes, I've identified the problem.
Well, of course I haven't identified the real problem. But I've found a suitable way to tiptoe around the problem.
I've developed a simple workflow that may help you as well.
A Simple Workflow
- Open the XAML file for editing. Whether or not you have design view visible in any way is immaterial. This happens in both code view and design view, and split-screen view.
- Make any and all changes.
- Save your file. (This step, while not necessary, will make it easier on you in the Visual Studio recovery process post-crash.) It's important to note that at this point you've entered The Danger Zone.
- Observe your task manager's real-time CPU chart max out one of your CPUs. You're still in The Danger Zone.
- Close all XAML files. You may leave code (C#) files open in Visual Studio if desired. This will trigger further processing.
- Continue to observe devenv.exe's CPU usage.
- When CPU usage drops to 0%, even for a short while, let out a yolp of joy! You've passed through The Danger Zone. Give yourself a pat on the back. (Yes, I mean physically give yourself a pat on the back. It's awkward, but you've earned it!)
- Now you can run your application without crashing Visual Studio!
Ways to know you're in The Danger Zone
1. Visual Studio crashes when attempting to "Play" or launch your WPF project from Visual Studio.
2. Visual Studio crashes when it receives focus again sometime while running your WPF app.
3. Visual Studio crashes when you terminate your WPF application.
Highway To The Danger Zone, by example
This just happened two minutes ago. I'll point out I avoided crashing Visual Studio again, thanks to my stick-to-it-iveness. Enjoy.
PS—I have a quad-core machine, so this graph represents one of the four CPUs entirely pegged by devenv.exe. I don't know why, nor am I particularly interested to report a bug. I just know how to avoid the crashing and whatnot.