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.
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:
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:
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>
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
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.
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.
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.
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.
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.
I just a situation where we were not able to open the Server manager MMC window on WIN2k8 Ent Server.
Replacing the C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config from working machine resolved the issue