I recently found two ways to crash the Visual Studio IDE. The first (and trickier of the two) involves adding a design time DataContext for a WPF User Control. Setting the d:DesignContext strikes me as still very useful but it helps to be aware of the potential dangers. It took me the better part of half a day to track the problem down.
The first mistake I made was I added a design time DataContext to a parent user control without making sure that all the child user controls were setting a design time DataContext. This isn't actually a requirement, but I would strongly suggest you always do this, because then you'll know what's really causing the crash. In my case, multiple generations down I had a very simple control that was unhappy but I didn't know it because the UserControl wrapping that simple control wasn't using a design time DataContext.
It Pays to Data Bind to the EXACT Matching Type
I was using the IntegerUpDown control from the Extended WPF Toolkit. It's a very useful control but it appears to be a bit persnickety when it comes to using the d:DesignContext. Keep in mind my XAML and code worked perfectly when running, it was just when Visual Studio went to parse the XAML that I had problems. It boiled down to the data binding on the Value property on the IntegerUpDown control. It expects to be bound to an int? (a nullable int) and I was binding it to a property of type int. You aren't going to get any compiler errors or warnings when you do this, or even any hints from ReSharper in the XAML code. Everything will look and work fine, until you add a design time DataContext. I suspect that when running I didn't have a problem because the Property was never null, but at design time it was.
If you're looking for another way to crash Visual Studio (aren't we all), Try referencing a view inside of itself. In my QuoteView.xaml I meant to write:
However, instead I wrote <Quote:QuoteView … /> which crashes surprisingly fast considering I have a lot of RAM, but maybe Visual Studio was able to short circuit running out of stack and just gave up and went home early.
The only reason I mention this bone-headed mistake is because prior to WPF I don't think I could ever do anything in my code to crash Visual Studio. That is no longer true and it's worthwhile to be aware of the price of progress.