[wix-users] Sanity Check: WMI Providers, GAC Assemblies, and Major Upgrades

[Bryan Dam]

We recently acquired another company and I'm working to integrate their endpoint/agent code into our installers.  The major wrinkle being that there's an older style WMI provider using the WMI.NET Provider Extension which requires that the assemblies be in the GAC.  Our upgrade strategy is to do Major Upgrades with AllowSameVersionUpgrades set to Yes and Schedule="afterInstallExecute".  We release monthly builds with a new build number (third version field) but we use AllowSameVersionUpgrades juuuust in case we need to throw a hotfix out there.

Doing some research it looks like back in the 2007 time-frame there was a known issue (here<https://docs.microsoft.com/en-us/archive/blogs/astebner/assemblies-may-be-missing-from-the-gac-or-winsxs-cache-after-an-msi-major-upgrade>) surrounding this scenario where the GAC assemblies are removed but not put back and therefore removed on major upgrades.  The solution being to either schedule RemoveExistingProducts after InstallFinalize or use assembly versioning and update the version each upgrade (here<https://docs.microsoft.com/en-us/archive/blogs/astebner/enabling-in-place-assembly-upgrades-using-windows-installer-and-wix>).  Our build system sets a global-ish version on everything already so the later option would seem like the way to go if we have to.

What I'm asking is: do I still have to? The company had a heck of a time fighting the upgrade scenario with Advanced Installer and essentially rewrote all the GAC/provider install logic into custom actions as a back-stop.  I'm trying to avoid having to do that if at all possible and just wondering if the above problems/strategies still hold true in 2021.  Second, does scheduling the major upgrade with afterInstallExecute (which we did to solve a versioning issue in a 3rd party dependency) preemptively solve that problem anyways?

       Thanks,
            Bryan