Software Versioning: Difference in Windows Installer and .Net Version

Question

Microsoft is promoting .Net for over 8 years now.

.Net assemblies are versioned using 4# versioning like major.minor[.build[.revision]]. Ref here

While, Windows Installer still suggests 3# versioning like major.minor.build. Ref here

With the difference in versioning in two systems. It is not straight to map .Net assemblies version to an installer. It is quite complicated to use Windows Installer for installing .Net applications, particularly when someone wants to implement Upgrading Product for any change in Revision.

How to overcome this situation? We want to Upgrade our product even if there is smallest change in Revision.

Answer 1

Why would you map .NET assembly versions straight to your product version? Do you really have only one assembly in your product?

Most product configuration management processes I've seen usually tracks product versions with manifests (aka bills of materials) listing what versions of binaries, configuration files and documentation goes in that product version. This decouples your development process from your release process, which is a Good Thing, not least for commercial products.

Answer 2

The versions used by .NET and the Windows installer address different concerns. In .NET, the assembly version is used by the loader to determine which version of the assembly to load. Remember, you can deploy the multiple versions of the same assembly to GAC and have them available side-by-side. You can even have policies that specify the exact version of an assembly to load. I can have different versions of assembly A in GAC and have application 1 using version 1 and application 2 using version 2. While I don't know that much about the Windows installer, I think it is using the version and the product guid to keep track of what version of an application installed so that it can determine if the application you're installing is newer than what's already installed and warn the user or uninstall it first or let the user choose.

Answer 3

I guess your problem is that windows installer will sometimes fail to update a particular file based on its version. The reason is that the File Versioning Rules do not take the revision part into account. Also, Windows Installer will not consider the file modification date (except to block the updating of unversioned "user data").

I see three different possible solutions:

Change your assembly version scheme

Don't use the revision part of the assembly version number, or make sure that it is never the only part that changes for a release.

Use only major upgrades with removal of old product

A major upgrade can be configured in such a way that the old product is always uninstalled first (see this wix example). Files will therefore always be updated regardless of their version. (Possible exception: see the "Permanent" attribute for the component element).

Override the file version for Windows Installer

The msi file contains the version information for each file. Wix normally takes this version from the file, but you can set the DefaultVersion attribute in the File element and then suppress the information in the file itself with the -sf switch ("suppress files") of the light.exe linker.

This way you can use a separate versioning scheme for Windows Installer that doesn't use the revision part. This may not be a supported "feature": the Windows Installer File Table documentation explicitly states that the Version column should match the actual file version.

Answer 4

This isn't something to overcome. It is a design limitation to accept and design around. Annoying yes but not something that is likely to change in the foreseeable future. Windows Installer ProductVersions are based on 3 parts. Also, remember the first two parts can't be more than 255 but the 3rd part can be up to 65,535.