[wix-devs] Rollback quirks

[Sean Hall]

> 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.

Actually, I'm not sure it's a good idea to re-detect during Apply because
we would have to do a complete Detect cycle to run all the searches and the
BA can do its thing in response to the various detect BA messages.

I think I understand what you're saying about ExePackages, if the
ExePackage didn't even have a detect condition then it wouldn't normally
uninstall. I think that means that an ExePackage should require a detect
condition (and be non-permanent) in order to schedule a rollback action of
uninstall. I'm not sure about basing it off of UninstallArguments, can Burn
even tell the difference today between UninstallArguments that were
authored as empty vs not specified? It's possible that the ExePackage knows
to uninstall with no arguments.

On Wed, Jan 13, 2021 at 2:23 PM Sean Hall <r.sean.hall at gmail.com> wrote:

> > 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 do think the fix for 5950 is to make it consistent for all packages. Are
> you aware that it's done this way for all operations, not just
> execute=install and rollback=uninstall?
>
> > It is probably a bit more complicated with ExePackages since they would
> need to re-detect
>
> If we do make the behavior consistent, I'm starting to wonder if we should
> do that for all package types to see whether or not to actually do the
> planned rollback action. In which case, why not just re-detect as the way
> to track whether it's installed?
>
> >> But what happens if the rollback also fails?
>
> You skipped the question in step 3, but your response makes it sound like
> you think the tracking should assume that the execute action was successful
> even if the exit code indicated failure. If we're making that assumption
> during execute, then yes we should make the same assumption during rollback.
>
> > 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?
>
> The current ARP behavior is useless to me. But if you want to know, in v3
> with the following scenario the registration is kept:
>
> 0. Bundle was not already installed, executing Install action.
> 1. non-permanent MsiPackageB is executed for install.
> 2. MsiPackageB returns success.
> 3. vital MsiPackageC is executed for install.
> 4. MsiPackageC returns failure.
> 5. Rollback is disabled so execution ends immediately.
>
> That's not the scenario I was interested in, though. I was wondering about
> what happens if MsiPackageB failed.
>
> > Aside: IIRC, Burn in rollback mode ignores cancel requests
>
> Maybe my reason for rollback failing is a bad example. Just imagine
> something else causing the same outcome, which could be much easier with
> ExePackages and brittle DetectConditions. (Also, v4 allows showing UI for
> MSI during uninstall).
>
>
> On Wed, Jan 13, 2021 at 1:38 PM Rob Mensching <rob at firegiant.com> wrote:
>
>> > 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/
>>
>