Why can't I install the .NET Framework SDK v1.0 on Media Center (or Tablet PC for that matter)?

  • Article

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:

  1. The .NET Framework 1.0 shipped a separate dotnetfx.exe for each non-English language of the product. Each of these packages contained an MSI that installed about 90% of the exact same files and some additional language-specific resource files, and this MSI had a different product code for each language. Because 90% or more of the product was the same for each language, all of the uninstall and servicing issues existed for non-English versions and we had to block the non-English .NET 1.0 packages from installing on Media Center and Tablet PC using the same application compatibility feature described above. However, this would have meant that users would have no way to install language-specific resource files on these OS's. So we decided to bundle all 9 languages of the resource files that shipped with the original .NET Framework 1.0 and install them on all langauge OS's for Media Center and Tablet PC. This was not exactly pretty and added a small amount of size bloat to those OS's (around 1 megabyte on the OS installation disk and around 10 megabytes on the OS after setup completed), but overall the solution has proven to work pretty well for us, and I can't recall getting any questions or complaints about this issue.
  2. The .NET Framework 1.0 SDK included the .NET Framework 1.0 redistributable files as part of their product MSIs. This made the SDK susceptible to the exact same set of uninstall and servicing issues described above. Since the SDK is a couple of hundred megabytes in size, we could not use the same strategy as we used for language resources. We decided to block the user from installing the .NET Framework 1.0 SDK on Media Center and Tablet PC using the same application compatibility feature described above. This means that a developer who wants to install the standalone .NET Framework SDK on these OS's is not able to. This decision was one of the hardest ones we made for this .NET Framework 1.0 OCM project, but we had to weigh the significant uninstall and servicing problems against the size of the market of people who would really want or need to install the standalone .NET 1.0 SDK on these OS's and against the available workaround of installing any version of VS .NET 2002 to gain access to .NET 1.0 SDK bits on these OS's if necessary. In retrospect, I think we made the best decision available to us considering these constraints. We have had a few customers inside and outside of Microsoft ask us why they can't install the .NET Framework 1.0 SDK and also ask why it tells them that the SDK is part of their operating system (this is the error message that appears when the application compatibility block kicks in and stops them from installing the .NET 1.0 SDK).

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.