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.
I was on a mail thread this week about a bug in the .NET Framework 1.1. There was a logic problem within Fusion that causes assemblies in the GAC to not be updated by Windows Installer if an assembly with the same assembly version but different file version is already present and if the string length of the file version is greater than the string length of the assembly version.
Our setup team found an instance of this problem immediately before shipping the .NET Framework 1.1 and Visual Studio .NET 2003 in this scenario: some internal customers had an RC (release candidate) version of the .NET Framework 1.1 and Visual Studio .NET 2003 installed, then uninstalled them in order to install the final build. Some folks uninstalled the .NET Framework 1.1 first, and if they had no other version of the .NET Framework on their machine there was no longer any version of fusion on the machine so uninstalling Visual Studio or the J# redistributable pack would leave behind assemblies in the GAC. When we attempted to validate the installation of the final build we found that some of the assemblies in the GAC were still the RC version.
At any rate, I found out this week that there was supposed to be a knowledge base article written for this issue but it ended up not being published, so I wanted to post the contents here. Note that this issue has been fixed in the .NET Framework 1.1 SP1 and in the upcoming version 2.0.
FileVersion attribute in assembly name table is not honored during install and uninstall of assemblies
There is a bug parsing the FileVersion=w.x.y.z attribute in the display name. Briefly, the parsing code takes a pointer to the attribute value and a size field. The size field passed in is the size of the assembly version rather than the file version. So, if the file version ends up being longer in length (string length) than the assembly version, we prematurely terminate parsing of the file version, and end up comparing the wrong file version. This could cause patches to not get installed when you think they should.
In the assembly name table, pad the Version field with leading zeros to workaround this problem. For example, if your assembly name is "Foo, Version=126.96.36.199, culture=neutral, publickeytoken=123456abcdef, FileVersion=1.0.3500.0" you would hit this problem since length of FileVersion field is longer than length of Version field. Modify assembly name to contain Version=00001.0.0.0 to workaround the problem.