I had again the not-so infrequent pleasure of setting up fresh copy of Windows development stack. We were moving few machines between projects and to make sure that no forgotten source files are left on the harddisk, we reformatted and reinstalled Windows from scratch. It is usually good idea anyway, because developers like to install strange tools and utilities and generally customize machines to their own taste, which tend to be unique and is seldom shared.
We needed to set up usual development tools: Framework 2.0, Visual Studio, SQL Server 2005 with AS, as we will be doing few OLAP related modules. Plus Subversion client, some 3rd party tools (such as Notepad++, TotalCommander, Putty, Firefox with developers plugins) and so on. Not a rocket science, obviously - just needs to be done in proper order and not forget to include all needed components. If you install on Windows XP Pro, the usual catch is to forgot installing IIS first. Without IIS, the ASP.NET does not get configured out of the box and you have to register it manually by running aspnet_regiis.exe -i command, well hidden inside the Framework directory. Which is exactly what happened - on two machines, because both were imaged from same image, lacking the IIS component.
So we did the above step and afterwards one of the machines worked just fine, whereas the other kept throwing weird error on every attempt to debug an ASP.NET application with VS 2005. Now the fun began. The error message was a bit misleading - indicating that the problem is in running/attaching debugger on ASP.NET process. But even the access to ASP.NET application was broken, giving back 500 Server error and recommending to check event log. Which we did - and found absolutely nothing useful in there. After some digging, fruitless googling, checking the user membership in various groups and accounts under which the ASP.NET process was running ... the solution to the problem were directory permissions. On the machine which worked, the directory hosting Web app was writable by group Users. On the other it was not. Setting permissions that allowed ASPNET account read and write the directory fixed it all.
So what is my point and why am I documenting this fairly uninteresting issue ? Few points and observations actually. First, it would be very helpful if with such huge and complex tools as Visual Studio Microsoft would provide some checks and diagnostics that would indicate which parts of tools work and which do not work. The error messages should be much more detailed and provide some context about what went wrong. In Java world, having the stack trace in Tomcat log file would immediately clarify what can and what cannot be the cause. Using plain old text files for logging is probably better that stuffing everything into event log. Event logs may be great for system admins and remote access, but for developers, text file with meaningful content is more than adequate.
Second, the approaches that some people use when troubleshooting installation problem are unbelievable. Relying on Google results will often lead you in completely wrong direction. I was amazed how many crazy things were people trying to get rid of the error message as ours: "What worked for me was to install framework 1.1, switch ASP.NET from 2.0 to 1.1 and then back". One cannot exclude that this may have impact - and even fix the problem - but obviously, the fix is caused by some side effect which may or may not work on your machine. What is actually happening is people are trying to fix something they do not really understand, by attempting random actions and observing the impact. The problem may be in low experience level of the users - but also in bloated, messy environment of Windows system files components and their complex inter-dependencies. These two together create strange culture of frustrated users trying to catch black cat in dark room - and in half of the cases, the cat is even not there.
Last but not least - without deep understanding what exactly gets installed where and how it depends on other components, you can be 100% sure what is the root cause of the problem - and where to look for solution. It would take us much less time to fix the issue if we were not try to fix assumably broken ASP.NET installation - because we knew we did skip one step, this was first thing to look at.
This is one thing where Java got it right - or at least much better than Windows. All you need to have is correct path settings (to include the version of JRE you want) plus JAVA_HOME variable pointing to it and rest is just making sure you have correct classpath that contains all jars. Adding components or plugins is matter of copying files to proper place, no installers and registry is involved. You can (and I do) have six different configurations and versions of Eclipse on your harddisk: one barebone, to test the new plugins, one with MyEclipse IDE, one with Web Tool Project, one with Ruby Development tools and RadRails (all 3.2 based), plus old 3.0 version to support older projects. I also do have three different installation of Apache Webservers - version 1.x, version 2.x and the "portable" version inside XAMP without any issues at all. Not speaking about approximately 5 versions of Tomcats and few other J2EE servers coexisting peacefully ...
Now just try to install and run side by side just two installations of VS2005 with different set of plugins - and compare the experience. Your best bet is run two full Windows installations inside VM or using two workstations ...