I decided to create a new post category for my blog entitled Mailbag. Periodically, I will pick out interesting questions that come from readers who post comments on my blog or send them directly to me via my contact link and answer them as standalone blog posts.
I will probably tend to pick questions that relate to interesting design or implementation decisions regarding features of Microsoft that I have worked on and that I know about some of the background behind. I will still continue to post about issues and workarounds to specific bugs in separate posts as I have time as well. I am planning to play this idea by ear and see how it works out over the next few weeks and then decide whether or not to keep it going long-term.
Without further ado, here is the first edition of my mailbag....
When I installed Visual Studio 2005, I found SQL Express in the feature tree and chose to install it. Then I decided to uninstall SQL Express (in order to install SQL Server 2005 Developer Edition), so I went to Add/Remove Programs and launched Visual Studio 2005 setup again and chose Add or Remove Features. However, SQL Express was not in the feature tree anymore. Why not? And how can I uninstall SQL Express?
In order to uninstall SQL Express, you can go to Add/Remove Programs and choose the item named Microsoft SQL Server 2005. Uninstalling this item will remove all relevant SQL 2005 items from your system (even though you will see several SQL-related items if you look around in Add/Remove Programs).
SQL Express is chained during Visual Studio 2005 setup so that it appears to be a feature in the VS setup feature tree. However, behind the scenes, it is actually a separate setup package that can be installed and uninstalled independently of VS.
Visual Studio 2005 setup contained a new feature designed to support chaining optional products after the main vs_setup.msi is installed. These optional products are separate standalone setup packages that can be installed as part of VS or on their own. We made a simplifying assumption when designing this setup feature - during initial installation of Visual Studio 2005, setup would detect whether or not the package is installed and offer to install it if it was not already present. However, VS does not offer the ability to uninstall the package as part of maintenance mode setup (though it will attempt to repair it if you choose to repair VS).
We decided not to integrate the uninstall because it would be overly complicated and error-prone to attempt to keep track of whether or not Visual Studio was the one to originally install the package and also keep track of whether or not other products on the system needed the package. Making an incorrect decision about uninstalling the package could leave other products on the system in a non-functioning state. For example, if some product other than Visual Studio 2005 relied upon SQL Express, Visual Studio 2005 could break that product if it uninstalled SQL Express out from under it.
The major benefit of this design decision was that it provided VS 2005 setup with the ability to selectively install packages via user choices in the feature tree. The primary scenario this solved was the common complaint from VS .NET 2003 that users were forced to install the J# redist even if they did not plan to do any J# development.
The major drawbacks of this design decision are the following:
- It creates a more complicated uninstall if you want to remove the entire VS 2005 product. This is seen most clearly in a lot of the beta uninstall issues where VS was uninstalled in the "wrong" order, which ended up orphaning old beta files on the system
- Installing VS 2005 creates a large number of entries in Add/Remove Programs
One other note about this question - it is not technically necessary to uninstall SQL Express in order to install SQL 2005 Developer Edition. It is a little bit redundant to have both installed, but it won't hurt anything because Windows Installer will reference-count things correctly. You will end up with an additional SQL instance on the system however.