I have an burn standard bootstrapper which chains one particular msi as follows
<Chain>
...
<MsiPackage Id="activex32" Cache="yes" SourceFile="$(var.MyPath)\activex32.msi" />
...
</Chain>
This msi follows the MajorUpgrade strategy: each build changes PackageCode and ProductCode, but keeps the UpgradeCode constant through builds.
The problem is, some people actually install this msi as a standalone package. And some of these people also want to install my bootstrapper, which was compiled with an older version of activex32.msi (lower build number). When this happens, the bootstrapper downgrades the activex32.msi.
I would like to know how to prevent this downgrading. Yes, I can update my bootstrapper with the latest activex32.msi, but that does not prevent the problem from happening again in the future.
Update: The log doesn't say much, in my opinion
[120C:14C8][2017-10-20T16:49:05]i103: Detected related package: {1CFD803C-D610-4414-B308-28FDD8326542}, scope: PerMachine, version: 8.11.0.19409, language: 0 operation: MajorUpgrade
[120C:14C8][2017-10-20T16:49:05]i101: Detected package: activex32, state: Absent, cached: None
[120C:14C8][2017-10-20T16:49:07]i201: Planned package: activex32, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[0CD8:0C04][2017-10-20T16:49:10]i305: Verified acquired payload: activex32 at path: C:\ProgramData\Package Cache.unverified\activex32, moving to: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi.
[0CD8:0C04][2017-10-20T16:49:10]i305: Verified acquired payload: activex32 at path: C:\ProgramData\Package Cache.unverified\activex32, moving to: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi.
[0CD8:12F8][2017-10-20T16:49:41]i323: Registering package dependency provider: {21C87035-C870-4C06-8978-290D4FD71D33}, version: 8.11.0.18409, package: activex32 [0CD8:12F8][2017-10-20T16:49:41]i301: Applying execute package: activex32, action: Install, path: C:\ProgramData\Package Cache{21C87035-C870-4C06-8978-290D4FD71D33}v8.11.0.18409\activex32.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"' [120C:14C8][2017-10-20T16:49:43]i319: Applied execute package: activex32, result: 0x0, restart: None [0CD8:12F8][2017-10-20T16:49:43]i325: Registering dependency: {eb25107d-62c4-49d9-a7c8-0957943ccbdb} on package provider: {21C87035-C870-4C06-8978-290D4FD71D33}, package: activex32
I did some more investigation and concluded that burn does not do much, if anything at all (?), to allow or disallow downgrades. It seems to leave that decision to the msi package itself.
In my case, the activex32.msi allows downgrading. When I changed it with Orca, modifying the Upgrade table to disallow downgrades, and compiled a new bootstrapper using this modified package, then everything worked and burn didn't downgrade the existing activex32.msi.
Kind of disappointing, since I don't control how the 3rd-party package is built.