CODEWITHSUNDEEP
wixbootstrapperburnwix3.9
Matt Long
Matt Long

Reputation: 85

WIX v3.9 Burn custom BA uninstalls related bundles last instead of first

We recently switched over to a custom bootstrapper for our installer. This allows the user to select from a list of possible modules to install (each as separate msi's). We are now making our first upgrade and have run into an issue. Burn properly upgrades the msi's but it's not properly dealing with the bootstrapper which is listed in the ARP. It attempts to uninstall the bootstrapper last but then fails because a higher version of the bootstrapper has already been installed.

According to this article https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order- the execution order for an upgrade should have the related bundle uninstalled first:

"When planning an uninstall, the Burn engine plans all related bundles first. Thus related bundles are always removed before the chained packages are removed.

However, that's not the behavior we're seeing. The related bundle is uninstalled last:

[11C4:0868][2015-02-26T10:09:26]i102: Detected related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, scope: PerMachine, version: 7.5.0.0, operation: MajorUpgrade
...
[11C4:0868][2015-02-26T10:09:38]i207: Planned related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
[11C4:0868][2015-02-26T10:09:38]i299: Plan complete, result: 0x0
...
[1224:0E20][2015-02-26T10:23:26]i301: Applying execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, action: Uninstall, path: C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe, arguments: '"C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe" -uninstall -quiet -burn.related.upgrade -burn.ancestors={36ff969e-da98-4c27-9dde-20e090c0812f}'
[11C4:0868][2015-02-26T10:23:35]i319: Applied execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, result: 0x0, restart: None
[11C4:0868][2015-02-26T10:23:35]i399: Apply complete, result: 0x0, restart: None, ba requested restart:  No
[11C4:0868][2015-02-26T10:23:38]i500: Shutting down, exit code: 0x0

We know there is no way to change the order, so how do we get the upgrade to work?

Upvotes: 2

Views: 1211

Answers (1)

Bob Arnson
Bob Arnson

Reputation: 21886

When you're installing an upgraded bundle, you're installing it, not uninstalling it. So the order is as the FireGiant article specifies for an install: The upgraded bundle is installed (usually upgrading the packages it contains) and the related bundle (the old bundle) is uninstalled. When the old bundle is uninstalled, it knows that its packages have been upgraded so it leaves them alone and just removes its own registration.

If your BA tries to prevent downgrades, it needs to also consider the action. For example, WixStdBA lets the uninstall happen like this:

if (m_fDowngrading && BOOTSTRAPPER_ACTION_UNINSTALL < action)

Upvotes: 2

Related Questions