[wix-devs] Rollback quirks

[Rob Mensching]

> None of the other package types were updated with this logic, causing issues like https://github.com/wixtoolset/issues/issues/5950

If it is helpful, I agree in 5950 it would be ideal if all packages rolled back the way MSI packages do now--if the package can be uninstalled (i.e. well-known uninstall or has UninstallArguments, etc.). It is probably a bit more complicated with ExePackages since they would need to re-detect to see if they were successfully installed before trying to launch their uninstall command. An ExePackage's uninstall behavior is too undefined to simply launch uninstall without knowing that the exe was installed.

> But what happens if the rollback also fails?

If rollback--or the uninstall command to replicate rollback if the package was installed--fails, I think we'll just have to move on with life pretending it worked. In other words, ignore rollback results. There are trade-offs here but my initial instincts tell me that removal even with rollback failure is the lesser of evils. A solid counter argument could absolutely sway me.

> Or maybe for DisableRollback="yes", we should never uninstall the bundle?

I'd have to defer to the current behavior of Burn with DisableRollback="yes". Does failure during install of a latter package in the chain with disabled rollback keep the Bundle registration or remove it? 


Aside: IIRC, Burn in rollback mode ignores cancel requests. I'm pretty sure this is the same behavior as MSI. The user can't cancel rollback.


-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, January 12, 2021 4:42 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: [wix-devs] Rollback quirks

I'm trying to implement 6297, but I'm getting hung up on how we're doing rollback for execute package actions. Remember that I'm trying to track what the actual state of the package is during execution, to get an accurate count of the number of non-permanent packages that are installed.

>From https://github.com/wixtoolset/issues/issues/3089, MSI packages are planned such that if there is a rollback execute action then that will be executed during rollback even if the package had failed. (None of the other package types were updated with this logic, causing issues like https://github.com/wixtoolset/issues/issues/5950).

So how do I handle failure of the non-rollback execute action? Should I be conservative like 3089 which would mean for example that even if the install failed, I treat it as installed? At first you might think that it doesn't matter, because rollback should undo it. But what happens if the rollback also fails? Also, if the bundle has DisableRollback="yes" then it would never try to rollback the package, and that could mean the difference between keeping the bundle registered or not. Or maybe for DisableRollback="yes", we should never uninstall the bundle?

DisableRollback="no" scenario:
0. Bundle was not initially installed, and had no packages installed or cached.
1. MsiPackageA is executed for install.
2. MsiPackageA returns error, but it actually installed successfully.
The user had canceled too late.
3. (Track this as installed or not?)
4. Rollback executes MsiPackageA for uninstall.
5. MsiPackagesA returns error, but it actually uninstalled successfully.
The user had canceled too late.
6. (If we tracked as installed in #3, then do we now treat it as uninstalled?)
7. MsiPackageA gets uncached.
8. We're supposed to uninstall the bundle here if MsiPackageA is not installed.
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/