2

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?

Matt Long
  • 85
  • 8

1 Answers1

2

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)
Bob Arnson
  • 21,377
  • 2
  • 40
  • 47
  • That makes sense, thanks. It sounds like my original installer (released to the world) is jacked and I'll need to fix the upgrading for future versions. If I'm right, I think I need to: In the old bundle, detect the related bundle and if the related bundle is an upgrade, call Engine.Plan(LaunchAction.Uninstall); plan the uninstall and apply, then exit the uninstall. – Matt Long Feb 27 '15 at 14:33
  • Opening the old bundle to uninstall causes the UI to open, is there a way to suppress that? – Matt Long Feb 27 '15 at 14:34
  • 2
    Burn automatically runs the older bundle with the -quiet and -uninstall switches. That will be passed to you in the command object. – Bob Arnson Feb 28 '15 at 00:00