Possible issue where machine.config can be overwritten by .NET Framework 2.0 SP2 setup

Description of the issue

I heard from someone recently who noticed that some information was removed from the file machine.config after installing the .NET Framework 2.0 SP2.  Their scenario looked like the following:

  1. Install Windows XP or Windows Server 2003

  2. Install the .NET Framework 3.5 (which installs 2.0 SP1 and 3.0 SP1 behind the scenes, and which adds some information about 3.5 assemblies to the 2.0 machine.config)

  3. Install the .NET Framework 2.0 SP2

  4. Look at the contents of machine.config (located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config on an x86 OS or C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config on an x64 OS)

In the above scenario, the entries added to machine.config during .NET Framework 3.5 installation in step 2 were removed from machine.config during .NET Framework 2.0 SP2 installation in step 3.

How to work around this issue

If you run into a scenario where machine.config is incorrectly overwritten when installing the .NET Framework 2.0 SP2, you can work around it in one of the following ways:

  1. If you have not yet installed the .NET Framework 2.0 SP2, you can manually back up your copy of machine.config, then copy it back after installing the .NET Framework 2.0 SP2.

  2. If you have already installed the .NET Framework 2.0 SP2, you can repair/re-install other products that updated machine.config (such as the .NET Framework 3.5), or you can manually re-add the information to machine.config that was removed by the .NET Framework 2.0 SP2 installation process.

  3. Instead of installing the standalone .NET Framework 2.0 SP2 package, you could instead install the .NET Framework 3.5 SP1 package (which will also install the .NET Framework 2.0 SP2 and 3.0 SP2 for you behind the scenes).  The .NET Framework 3.5 SP1 installation process will add the necessary information to machine.config that may otherwise be missing in this scenario.

What can cause this issue

.NET Framework 2.0 SP2 setup follows the standard Windows Installer file replacement logic for unversioned files, which causes it to not replace machine.config if that file was updated by some other program after it was originally installed.  However, we have seen some cases where the last modified time stamp does not get updated during .NET Framework 3.5 setup.  If this happens, then the installation of the .NET Framework 2.0 SP2 does not correctly recognize that some other program has updated machine.config, and as a result, the .NET Framework 2.0 SP2 installation process overwrites machine.config with a default copy that is included with the .NET Framework 2.0 SP2 installer.

One note – so far, we have only seen this issue affect computers that have an MSI-based version of the .NET Framework 2.0 installed (Windows XP, Windows Server 2003).  The issue does not appear to affect versions of Windows that include the .NET Framework 2.0 as an OS component (Windows Vista, Windows Server 2008, Windows 7).

<update date="12/29/2009"> Added another possible workaround for this issue - install the .NET Framework 3.5 SP1 package instead of just installing the .NET Framework 2.0 SP2 package. </update>


Comments (7)

  1. ran.davidovitz@gmail.com says:

    Aaron, this post raises a flag for me, how can I take confidence on the mechanism of the file replacement?

    Taking in mind that our company would like to go to working with MSP and we do have configuration files that are allowed to be changed by newer patches (or worse by user <Bug/> ), the above scneario is a big risk (this is still in the use case of no version & Hash)

    Have you had incidents with Windows Installer 4.5+ or 3 only

    Thanks for sharing

  2. Hi Ran Davidovitz – In the cases I’ve seen of this issue so far, Windows Installer was doing the right then when it decided to replace the file during .NET Framework 2.0 SP2 installation.  The created and last modified time stamps on machine.config were both the same (meaning that Windows Installer thought it hadn’t been modified), and the file hash of the new 2.0 SP2 copy didn’t match.  I don’t know the root cause of this issue for sure, but it is possible that some custom action that modified machine.config was not causing the last modified timestamp to get updated or something like that.

  3. pls2000 says:

    In a sense this is an installer (MSI) problem. The installer has provisions for updating a .ini file on an entry by entry or value by value basis rather than replacing the entire file.

    There is no corresponding feature for merging updates into an XML configuration file. Since XML config files are replacing .ini files, there really should be.

  4. Hi Pls2000 – In a way, yes, this is an overall Windows Installer issue because there is a limit to the built-in functionality it has for updating configuration files, which can force setup developers to need custom actions instead of being able to use standard actions.

    However, for the specific question that Ran Davidovitz asked above, the root cause of the .NET Framework setup issue described here isn’t caused by a bug in Windows Installer’s file replacement logic, it isn’t affected by which version of Windows Installer is on the end user’s system, etc.

  5. tbarcelon@hotmail.com says:

    Hi Aaron,

      In your workaround options, you suggested re-adding the sections that were removed. Do you know what they are so we can code our installers to always add these "possibly missing" sections whenever .net 3.5 is detecting as being present on the machine? Thanks.

  6. Hi Scienter – Doing this could be a bit tricky.  You could do a diff of a machine.config with and without those sections to see what is missing, and then manually add those sections in a custom action in your installer or something like that.  However, any .NET application could update machine.config, so this would only help in the case of the .NET Framework 3.5-specific entries.  Another option here is to install the full .NET Framework 3.5 SP1 package (which will install 2.0 SP2 and 3.0 SP2 for you behind the scenes) instead of only installing the standalone 2.0 SP2 package.

  7. AJmal says:

    I just a situation where we were not able to open the Server manager MMC window on WIN2k8 Ent Server.

    Replacing the C:WINDOWSMicrosoft.NETFramework64v2.0.50727CONFIGmachine.config from working machine resolved the issue

Skip to main content