WPF Designer causes Visual Studio to Close

Okay, so we all know that the WPF designer in Visual Studio 2008 is suboptimal. And if you didn't, now you know. Besides not being particularly user friendly, it's buggy as hell.

Today, while trying to demonstrate the basics of XAML / WPF, I was trying to show the design view of a WPF Window. The problem was, every time I opened the designer, the IDE would just close. No error, no beep, just gone. That was awesome.

Here are the things that I did that didn't solve the problem:

• Cursed.
• Rebuilt all.
• Cleaned solution, then rebuilt all.
• Manually cleaned the solution by deleting the bin and object folders under each project in the solution.
  
• Closed the solution and deleted the .suo file (Solution Options File).
  
• Closed the solution and deleted the project user files.
  
• Rebooted.
• Cursed when it still didn't work.
• Contemplated Harakiri.
  

Here's what did work:

• Deleted all of the temp files in the temp directory.
  

WTF? So in XP, here is the temp directory that was causing the issue (it's a different path in Vista):

C:\Documents and Settings\\Local Settings\Temp

There were like almost 5,000 files in that directory. Apparently, the designer creates temp files. My best theory is that tt will keep bogging down trying to find unique temp file names until one day it runs out of combinations. Then there is no call for help, no suicide note, it just quietly and inexplicably goes away. It doesn't even hang itself (no process remains in Task Manager).

I had discovered this fix many moons ago, and had of course forgotten about it until months later when my temp directory filled up.

Nomadic Programming

No, I don't mean driving all around town to program... Which isn't to say that wouldn't be fun. This refers to the tendency for a team to work on almost every module of a product at the same time.

So, how do you tell if this is happening? Draw a picture of your project. Break down your project into its major components. Pick a color scheme. This one is pretty straightforward:

• Red - the module hasn't been touched
• Yellow - the module is in progress
• Green - the module is code complete.
  

And you'll end up with something like this:



Holy crap - there are very few modules that are complete, and very few that are untouched. That means that the team is wandering all over the featurescape almost randomly coding on different modules. This approach has all sorts of dangers:

• This makes it very hard to ever get a project done because no individual item ever is completed.
  
• This approach leads to the "throw it over the wall to testing at the end of a long development" method. Not a good thing. For example, a fundamental flaw in design / implementation could have happened months ago and propagated to the rest of the product. That could easily lead to orders of magnitude to fix all of those issues.

If all is going well, we would expect to see a very small part of the diagram showing up in yellow (in progress) with the rest of the modules being either red (untouched) or green (completed).