A site devoted to discussing techniques that promote quality and ethical practices in software development.

Tuesday, October 16, 2007

The most bizarre installation I have ever experienced

I have been using and beta testing Visual Studio since it was 1.x and with the release of VS2008 VSTS Beta 2 some months ago, I am obviously eager to try to install it on my machines.

I must say, this has to be one of the hardest and toughest VS beta installation that I have dealt with so far. As you will see that I have to engage one of the weirdest and most bizarre techniques to finally crack the installation.

I must admit I had lots of very alpha .Net framework 3 stuff installed on my previous machine. Hence, I would expect the VS2008 Beta 2 to fail to install. Even after I'd cleaned up all those crumbs, it still failed. But I was shocked when this happened to me on a new machine with only released version of .Net Framework on it.

Anyway, when I performed the normal VS2008 Beta 2 set up on a machine with VS2003 and VS2005 VSTS, the process proceeded normally but hung up on the installation of .Net Framework 3.5. The presence of those released products should not matter.

After several attempts and probing the process, I decided to try to install just the .Net Framework 3.5 alone. This installation proceeded to about 80% and then hung.

Searching the net looking for similar symptom, I came across this one that described installation problem behind an authenticated proxy, a situation similar to mine. Armed with information from Aaron's blog, I ventured into the installation log to try to discover what's happening.

The installation appeared to be hung on trying to access a web site as reported in the last 3 lines of the file dd_dotnetfx35Install.txt and they are reproduced here:
[10/15/07,16:41:18] Setup.exe: GetGlobalCustomProperty - Property:   {8297A38B-6431-4F1D-9F6E-C3D371CEA383} - PropertyName: WebSetup - Value: 1
[10/15/07,16:41:18] VS Scenario: Checking if new setup is available. Url=
[10/15/07,16:41:19] VS Scenario: http://go.microsoft.com/fwlink/?LinkId=91778&clcid=0x409
Armed with the weird suggestion of unplugging the Ethernet cable from the wall, cleaning up all the crumbs (those folders in C:\ with a GUID as a name) and rebooting the machine to ensure no likely installation was still running, I decided to give this a try.

First I tried the .Net Framework 3.5 installation and this flied past the furthest part I had ventured. So my confidence was boosted.

Then I decided to cancel that installation to proceed with the real VS2008 Beta 2 set up. That also went flawlessly to a no-error completion!!

What a bizarre experience. Don't know why an installation program wanted to access a site. Furthermore, I could access that site from IE and that caused me to initially doubt that could be the reason why the installation was hung. But that seemed to be the stumbling block.

Unusual and Bizarre.

1 comment:

Anonymous said...


This experience is a great argument for self contained installation packages. While developers are always trying to keep the install package size down to facilitate faster downloads, they sometimes do so by including code to automatically download content on demand. When that mechanism breaks due to an error, or the web server being down, you can be prevented from successfully installing the application.

In addition, because of the multitude of processes that are executed during an install sequence, it is often difficult to present useful error messages to the user to assist them through the problem, other than the log file (assuming they requested to generate one, which most of us don't).

I think for most situations, an install should be as self contained as possible, and if there is a dependancy on another system which you don't want to include in your install (such as the .NET framework), then it might be better to make it a Launch Condition, rather than attempting to download it on demand.


Blog Archive