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

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.


Comments (3)
  1. Paul Ballard says:

    It’s interesting getting more insight into the deployment issues around the .NET Framework. Do you (or anybody else for that matter) know when we will be able to install a version of the .NET Framework 2.0 on MCE? Currently it blows up the Media Center extensions to XP if you install the Beta 2 (See my blog for more info).



  2. Hey Paul – that is a great question and one I have also been meaning to blog about. I’ll answer it here and transfer it to a standalone post later this week.

    The short answer is that the version of Media Center we’re currently working on will have this fix so that you can install .NET Framework 2.0 and not have it interfere with Media Center functionality.

    In the meantime, you can use the following steps to manually fix your machine to work around this issue:

    1. Go to %windir%ehome on your Media Center machine

    2. Create files named ehrec.exe.config, ehrecvr.exe.config, ehsched.exe.config, ehshell.exe.config and medctrro.exe.config

    3. Open each of these files in notepad and add the following information to them:



    <supportedRuntime version="v1.0.3705" />



    4. Restart your machine so that the config file changes will take effect for processes that might have already been running when you created the files

    Also, as a convenience, I created copies of these config files with the correct contents. So instead of steps 1-3, you can download the config files from http://astebner.sts.winisp.net/Tools/mce_config_files.zip and extract the contents to %windir%ehome on your machine and reboot and you should be good to go.

    Hope this helps!

  3. I got some feedback from Paul Ballard based on my blog post yesterday about why we block users from installing…

Comments are closed.

Skip to main content