Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
I've been meaning to tell this story for a while, and now that I'm working on the Media Center team, this story ends up being a nice intersection between my first team at Microsoft and my current team. So, here it goes....
When I was on the Visual Studio and .NET Framework setup team, one of the most interesting projects I got to work on was the integration of the .NET Framework 1.1 into OS setup for Windows Server 2003. This project required our setup team to convert our MSI-based installer into an OCM installer that can be run during OS setup. We started this project in between beta 1 and beta 2 for .NET Framework 1.0 in order to be able to test with pre-release versions of Windows Server 2003, and we checked in beta builds of .NET Framework 1.0 to Windows Server 2003 periodically throughout the .NET 1.0 product cycle (if you were in the beta program for Windows Server 2003, you might have noticed .NET Framework 1.0 being installed with the OS back then).
Somewhere during the final phases of the .NET Framework 1.0 and Visual Studio .NET 2002 ship cycle, the Windows XP service pack 1 project was getting going. The Media Center and Tablet PC teams were working on their first releases to coincide with XP SP1 and they were writing their features in managed code using the .NET Framework 1.0. There was a decision made to create new editions of Windows XP for Media Center and Tablet PC, and we needed a way to get the .NET Framework 1.0 installed as part of those OS's so managed code would run correctly out of the box to support their new features. Since our team was already in the process of doing this setup conversion work, the decision was made to back-port this work and make it work for the .NET Framework 1.0 on Media Center and Tablet PC OS's.
The final decision to use an OCM installer to deliver the .NET Framework 1.0 to these new Media Center and Tablet PC editions of Windows XP was made right after we shipped the MSI version of .NET Framework 1.0, and this introduced a new set of scenarios that we had not designed for or tested. Specifically, we had not planned for any kind of interations between a version of the .NET Framework 1.0 installed by OCM and a version of .NET Framework 1.0 installed by MSI. Because the .NET Framework 1.0 MSI had already shipped, this limited our engineering options, and we already knew based on our knowledge of installation technologies and some high-level proof-of-concept testing that if we allowed the user to install and uninstall the .NET Framework 1.0 MSI on Media Center or Tablet PC, the reference counting schemes would not work correctly and some files and registration would be removed out from under the features in these OS's that needed them. In addition, creating and installing service packs and hotfixes for the .NET Framework would have become more complicated if we alllowed a computer to have the .NET Framework 1.0 installed on it using both the OCM and MSI technologies.
As a result of these scenarios and some others that I am probably forgetting (since this all happened back in early 2002), we decided to block the user from installing the .NET Framework 1.0 MSI on Media Center and Tablet PC computers since it will already be installed by OS setup using the OCM version. We worked with the Windows application compatibility team to have them implement a hard-coded block for the .NET Framework 1.0 MSI on these OS's. This block intercepts MSI installation requests and compares the product code against a known list, and if the product code is on the list then the installation is blocked. It is basically impossible to get around this block without some serious hacking/reverse engineering that would be unsafe for future servicing of the product.
This decision was complicated by a couple of poor setup designs that existed in the .NET Framework 1.0 timeframe that have since been fixed:
As a side note - if you are familiar with the setup and packaging for the .NET Framework 1.1 and 2.0, you will notice that both of the complicating issues listed above that affected the .NET Framework 1.0 were addressed starting in .NET 1.1. We split the language resources into separate satellite language packs and consolidated the common files into a single "core" redistributable package with a single MSI product code. In addition, we decoupled the redistributable files from the SDK files and made the .NET Framework SDK setup block and require the user to install the redistributable package as a prerequisite.
The other cool thing about this .NET Framework 1.0 OCM project was that we got some practice working through OCM/MSI setup technology interaction issues. As a result, we learned some key lessons before we shipped .NET Framework 1.1 as a part of Windows Server 2003 and engineered solutions before that product shipped.