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:
- Install Windows XP or Windows Server 2003
- 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)
- Install the .NET Framework 2.0 SP2
- 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:
- 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.
- 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.
- 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
Anonymous
December 22, 2009
The comment has been removedAnonymous
December 22, 2009
The comment has been removedAnonymous
December 23, 2009
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.Anonymous
December 28, 2009
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.Anonymous
December 29, 2009
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.Anonymous
December 29, 2009
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.Anonymous
October 26, 2010
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