[wix-users] Minor upgrade with awful third party component versioning

[Leikis, Russ]

Hello,

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?

Thanks.