[wix-devs] Rollback quirks

Sun Jan 17 12:40:17 PST 2021

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

That's a good point. I overlooked how complex a detection chain could get. I don't have a good solution to this problem and I'm still wary of running uninstall on a ExePackage if it wasn't detected. Maybe that means ExePackage shouldn't behave like MsiPackage during rollback?

> ExePackage should require a detect condition (and be non-permanent) in order to schedule a rollback action of uninstall

Very recent change (like last week), compiler now requires a DetectCondition when UninstallArguments are provided (fixed an open bug). So, this should always be satisfied.

> It's possible that the ExePackage knows to uninstall with no arguments.

I don't believe this is supported today. IIRC, no uninstall arguments means ExePackage is not uninstallable (arguably the same thing as ExePackage/@Permanent='yes').

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

> 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/
>>
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/