This would not normally be a huge concern since the members of the components, the files, are not going to change. However, I did run into an interesting issue. Because my company’s versioning scheme is MAJOR.MINOR.REVISION.BUILD where BUILD is a value auto-incremented by the build server, as far as MSI is concerned 220.127.116.11 is the same version as 18.104.22.168. And because our patch strategy is to simply release a hot-fixed MSI, we have to allow same-version upgrades.
Anyone familiar with MSI upgrades knows the dirty secret that allowing same version upgrades allows same version downgrades. Except these downgrades would result in files disappearing from the filesystem. After much research I determined the issue was because of my stupid decision to group multiple files into single Components. MSI was not applying the standard file versioning rules correctly, and thus during a downgrade the following steps were occurring:
- Version X is installed on a system and user attempts to install version X-1.
- The installer appears to calculate which Components need to be installed by version and date. It does not include the X-1’s Components because they are already on the system.
- The installer removes X’s Components from the file system.
- Finally, the installer chooses not to install X-1’s Components because the installer has already calculated that the Components on the filesystem, at version X, were newer.
I found myself in quite a pickle. How do I prevent same version downgrades when the only varying component of the version is the 4th component (which again, MSI ignores)?