[wix-users] Minor upgrade with awful third party component versioning
rob at firegiant.com
Fri Feb 12 20:59:19 PST 2021
Easiest way out is to install to a new folder (or filename). Windows Installer really dislikes downgrading files.
Short replies here. Complete answers here: https://www.firegiant.com/services/
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Leikis, Russ via wix-users
Sent: Friday, February 12, 2021 8:46 PM
To: wix-users at lists.wixtoolset.org
Cc: Leikis, Russ <russ.leikis at mksinst.com>
Subject: [wix-users] Minor upgrade with awful third party component versioning
I've got a difficult problem. We've been using a licensed set of third party assemblies in several of our products. These assemblies were versioned as year.major.minor.build, (e.g. 2019.6.4.4001). We have several versions of several products published with these assemblies. We use Burn to bundle, and all assemblies not covered by a redistributable are harvested via Heat, including these third party assemblies.
The third party vendor has recently released a new version where they have changed their versioning to something more reasonable, following the major.minor.build.revision versioning scheme, (e.g. 10.0.1.4001).
We are nearing a release of one of our products and have discovered that the upgrade path of our products are now broken due to this versioning issue. During the costing sequence the old files are determined to be a higher versioned component and then the upgrade installation does not copy any of the new files. I believe I have tried every permutation of MajorUpgrade properties, but this lacks flexibility. So I've been working through the Upgrade table properties hoping to isolate a bracket of my released product versions with special behavior to handle this problem. I also understand that Burn limits the REINSTALLMODE options.
Despite any behavior change of MajorUpgrade, UpgradeVersion, and REINSTALLMODE, the underlying problem appears to be that while I am able to fully remove the previous installation, in every permutation the old files are determined to be a higher versioned component before the removal of the previous version can be legally scheduled. So even if I am removing the previous installation, the new files are not copied. This determination is noted in the bundle log.
I am trying to get to a scenario where the old installation is removed, then the new installer runs and finds that no prior installation is present. The built-in upgrade options don't appear to be able to solve this problem. The next idea I have is to abstract the third party assemblies into their own feature, so that they can be considered an 'added' feature versus the old published installers. Or perhaps I may have to have other external code to uninstall the previous versions by command line, or some custom action scenario.
Before I elaborate our installer code, I want to ask: Is there a viable solution to successfully upgrade a higher versioned component, with a lower versioned component of the same name? What information ought I provide here?
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users