Quick Review: Microsoft Visual Studio 2008

I've been using the Microsoft Visual Studio product line for over a decade. I've had my share of complaints about each version, to be sure. However, I've been using VS 2008 for about 4 months (previously using VS 2005), and have the following (super-quick) review: Upgrade.

Comments:

I've found the upgrade path quick, simple, and most importantly, stable. I still have VS 2005 installed, and have encountered NO problems. The upgrade was smooth, and most of my VS 05 settings migrated w/o issue. There were a few minor things here and there, mostly dealing w/ toolbar customizations and external tools under the Tools menu, but by and large, it was a no-brainer process. Unlike VS 05 which had a tendency to nuke toolbar customizations with the drop of a hat, the VS 08 toolbar (and other customizations) have been rock-solid.

I've found the IDE to be much less buggy than VS 05 -- so far no crashes, hangs, etc. Also, the startup times are greatly improved over their predecessors -- a few seconds or less on an average developer-class machine. Project load times also seem quicker. Compiling may be faster, but haven't done any timings or anything specific to determine if there are actual improvements or just user-perception.

Code migration for existing (.Net 2.0) projects was simple and painless. Not much to do other than convert the solution/project, definitely less hassle than migrating from 1.1 to 2.0.

One bug (at least in my opinion) that persists from VS 05 deals with the Object Browser. One of the projects that I'm working on has C#, managed and unmanaged C/C++ code. When using the browser, it is a real dog -- taking up to 30 seconds or longer to browse for the symbols. In watching the status bar, I see most of the time in the C/C++ code. Obviously browsing in C/C++ code is expected to be slower, but the real problem is that it keeps refreshing every couple of seconds, essentially locking up the UI. The solution is to clear the text in the Object Browser search or close the browser altogether. FWIW, browsing against a user-defined Custom Component Set that excludes the C/C++ code results in browse times of 5 seconds or less.

Other than that, very pleased w/ this rev. of the product. Strongly recommended just for the improvements in the responsiveness of the IDE, not to mention the support for C#/.Net 3, etc.

Disabling Unhandled Exception Dialog on Automated Build Machines

I'm currently working on a project that uses several automated build machines for both integration (quick) and release (long, exhaustive) builds & tests. The software development team defines the configuration of these machines, but they are administered exclusively by the IT department.

Recently, one of the issues that we have run across is that an executable, during the course of testing, may throw an exception. Obviously a problem with the executable/test, but the consequence of the exception is that the Windows Unhandled Exception dialog is displayed and essentially locks the build until an admin can terminate the offending executable and restart the build.

Obviously the intent is that an automated build machine can run in unattended mode (read: no user input!). The Windows Unhandled Exception dialog doesn't sit well for that assumption. So, I spent a little time to see if there is any Windows setting(s) that can be tweaked to disable the dialog. Here is what I was eventually able to find (done on the build machine):

1) Disable Windows Error Reporting

(Assumes Windows XP, SP2; newer/older OSs may have slightly different navigation.) From Control Panel, System, Advanced, Error Reporting: select "Disable error reporting" and clear the "But notify me when critical errors occur" checkbox.

2) Disable JIT in Visual Studio

(Assumes you are using this as the compilation tool on your build machine.) From VS (assuming VS 2005 menu navigation), Tools, Options, Debugging, Just-In-Time: disable (uncheck) all handlers (e.g. Managed, Native, Script). As a note, through my limited evaluation of the interaction between JIT and Error Reporting, it looks as if this step isn't strictly necessary. I did a quick test (disable Error Reporting, enable JIT), and no Exception dialog was displayed -- YMMV.