One of the most interesting challenges for me as a member of the Windows SDK team is that we ship so many products. Between Betas, CTPs and RTM releases, I’ve probably been part of at least a dozen releases since I joined the team in June 2005, and we have three more major releases in the pipeline for 2007. What’s extra complicated about that is that each of the releases has their own unique sets of content. How do pre-release SDKs live alongside released SDKs? How does each RTM SDK treat each other RTM SDK? How do we manage our content when multiple copies of the same content are installed by different products?
As the Setup Program Manager for the SDK, it’s my job to worry about things like these. I’ve created a matrix that shows the expected behaviors when products are installed one on top of the next, but the matrix is, by its nature, massively complex. My spec that lists the scenarios around this has 16 different scenarios listed, and I’m constantly concerned that I’ve missed one or two key scenarios.
Thankfully, the scenarios for install boil down to a few clear rules. We decided early on that pre-release and RTM versions of the SDK must live side by side on the user’s machine. A pre-release can never overwrite an RTM version; otherwise, the users would have release-quality content overwritten by Beta content. That’s obviously a bad, bad scenario. Another rule is that when the user has an SDK that has almost the same content in it – as in when the user has one of the three versions of the Windows SDK that are almost the same (the RTM SDK, our SDK Update or our Japanese-language version of the SDK) we just ask you to uninstall one SDK before installing another.
That solution works, but, to me, it’s not the perfect solution. The better solution to me is something called Reference Counting, or RefCounting. RefCounting is a MSI Custom Action which we use to track which content is installed by which application. If the content would be installed by more than one version of the SDK, we don’t install it more than once. Instead, we simply track that more than one application has installed the content.
As an example, if you installed the Windows SDK Tools for the .NET Framework through Visual Studio “Orcas” and also through an install of the SDK, the tools won’t be installed twice. They’ll be dropped to disk once, and the Setup Custom Action will write a registry key to note that the file was installed by both apps. In that way we prevent disk sprawl and also prevent users from breaking one product when uninstalling another product.
RefCounting is generally thought of as applying to uninstallation, but we use it to help with our install story as well. We get installation detection from the way we deal with product codes in the SDK MSIs. If the same product code for an MSI is in place, the MSI simply doesn’t get installed. At the same time that install is skipped, the RefCounting Custom Action also writes to the registry that another product is sharing that MSI. At uninstall, then, RefCounting queries the Registry and sees what apps have used that MSI. If more than one installed SDK uses that MSI, the MSI stays on disk while the product is simply RefCounted down by one iteration.
This process is crucial to our hopes of producing multiple localized Windows SDKs for future SDK releases. If we were to release an SDK with Japanese content and at the same time release content in some of the other Visual Studio-supported languages, it would create massive disk sprawl. Instead, through this scheme, we’ll be working to enable to allow you to install multiple versions of the .NET Framework documentation while only installing only one version of the Win32 samples.
It would help our decision making a lot if you gave us an idea of how you manage content on disk. Would you expect more than one copy of the same content to be installed, or would you prefer one copy? When do you expect our setup to upgrade for you, and when would you expect it to install side by side?
Setup Program Manager, Windows SDK