A quick tip is to cache your .pdb files onto your local machine when debugging .NET. This means that each time you debug the source then you don’t suffer the performance hit of downloading all the files again.

In Visual Studio go to Tools->Options and navigate to Symbols.

Make sure you deselect the option to search the above locations and cache the files. In the example I have created a folder on my c:\ drive called RSCC where the files are saved.

A new feature in the Visual Studio 2008 service pack 1, is background compilation of code to check for errors as it’s written. This facility has existed in Visual Basic for some time now, though I doubt it was ever this fast. What you get in the IDE is a red squiggle (similar to a spell check error) notifying the programmer a mistake is made. In this example I am mistakenly trying to assign a string value to an integer.

This type of error checking is all-over-the-place and saves one significant amounts of time, principally because errors are corrected sooner, meaning one doesn’t compile a project and then find loads of errors. I have a huge project, that I feel is being slowed down by this, and need to check whether the background compilation is affecting "snappiness" of the IDE.

To do this (In Visual Studio) go to Tools and then Options.

In the Options dialog select the Text Editor node, then C# and go the the Advanced node. Remove the check in "Show live semantic errors" to disable background compilation, or conversely check it to enable the feature.

I would be interested to know if other users are experiencing a sluggish IDE – especially in the larger projects. It therefore "appears" that for larger projects, the time you save in fixing silly errors, is lost in IDE speed – disproportionate of course – but further testing is required.