[wix-devs] WIXBUG5750 and RollbackBoundary
Rob Mensching
rob at firegiant.com
Tue Jan 23 08:38:22 PST 2018
Bob's recollection is correct. These are the scenarios to think about:
1. .NET Framework + Boundary + All your stuff == this boundary prevents the experience of installing then on failure removing .NET Framework. No one wants to go through that. The Bundle ARP entry is (should be) gone so the cached "All your stuff" packages should be removed. This (unfortunately) was a late scenario (particularly the ARP behavior) that made things ugly (as per Sean).
2. Your Vital Stuff + Boundary + Your Optional Stuff == this boundary is to help get the user to get a working product and not have some non-important package force everything back. In this case, ARP stays and stuff can stay in the cache. Idea is the user wants that stuff and will probably try again. If the user doesn't want any of it, well they need to uninstall anyway.
Regards,
Rob Mensching
CEO
FireGiant
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, January 23, 2018 8:28 AM
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] WIXBUG5750 and RollbackBoundary
I think it's easier right now to just say that the behavior is undefined for whether a package will still be cached in those scenarios. Like Rob has said, at some point we need to redo how Burn handles caching and this is one thing that could be addressed.
On Tue, Jan 23, 2018 at 10:05 AM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:
> I'm liking the simplification of if it's in ARP, then the cache can
> stay, however the current plan executes a rollback of a cached package
> if it fails. Are you saying this behavior should change, or just the
> concept of cleaning the cache should only happen if ARP = False?
>
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On
> Behalf Of Sean Hall via wix-devs
> Sent: Monday, January 22, 2018 11:52 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] WIXBUG5750 and RollbackBoundary
>
> I agree, if the bundle is going to stay registered in ARP then it
> should be allowed to keep packages in the cache. And it sounds like a
> good idea to try not to clean the cache to save time for a later attempt.
>
> I haven't looked at the code, but I would expect the
> Chain/@DisableRollback to essentially insert a RollbackBoundary
> between every package.
>
> (I numbered your examples below)
>
> (1) A stays installed, so bundle stays registered in ARP, so cache can
> stay.
> (2) same as 1.
> (3) A is rolled back, nothing is installed so bundle unregisters from
> ARP, all packages and bundle are cleared from cache.
> (4) RollbackBoundary causes the rollback to stop there. A stays
> installed, so bundle stays registered in ARP, so cache can stay.
> (5) same as 4.
> (6) same as 1.
>
> On Mon, Jan 22, 2018 at 5:17 PM, Bob Arnson via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
> > My vote: Cache should be tied to registration, so "registered in ARP
> > == cached as originally requested." Just because a package failed to
> > install shouldn't eject it from the cache, if the bundle is still
> > registered (so the user can try again without another download).
> >
> > As I recall (and I don't entirely trust my recollection as I wasn't
> > physically present or deeply involved at the time), package vitality
> > and rollback boundaries were to prevent a transient or simple
> > failure from triggering a painful (in time consumed) rollback and reinstall.
> > IOW, keep as much on the machine as possible so the user could retry.
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On
> > Behalf Of Hoover, Jacob via wix-devs
> > Sent: Monday, 22 January, 2018 17:34
> > To: WiX Toolset Developer Mailing List
> > <wix-devs at lists.wixtoolset.org>
> > Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > Subject: Re: [wix-devs] WIXBUG5750 and RollbackBoundary
> >
> > Also, what would the expected state of the cache be under this condition:
> >
> > (6)<Chain DisableRollback="Yes">
> > <MsiPackage SourceFile="A.msi" />
> > <MsiPackage SourceFile="Fail.msi" />
> > <MsiPackage SourceFile="B.msi" />
> > </Chain>
> >
> > Should B still be cached?
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On
> > Behalf Of Hoover, Jacob via wix-devs
> > Sent: Monday, January 22, 2018 4:06 PM
> > To: WiX Toolset Developer Mailing List
> > <wix-devs at lists.wixtoolset.org>
> > Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > Subject: [wix-devs] WIXBUG5750 and RollbackBoundary
> >
> > With regards to a rollback boundary, what is the expected behavior
> > of Burn when a package is authored with or without explicit rollback
> > boundaries, and an error happens during apply execute?
> >
> > Chain/@DisableRollback - The default is "no" which indicates all
> > packages executed during the chain will be rolledback to their
> > previous state when a vital package fails. If "yes" is specified
> > then when a vital package fails to install only that package will
> > rollback and the chain will stop with the error.
> >
> > RollbackBoundary/@Vital - Specifies whether the rollback boundary
> > aborts the chain. The default "yes" indicates that if the rollback
> > boundary is encountered then the chain will fail and rollback or stop.
> >
> > (1)<Chain DisableRollback="Yes">
> > <MsiPackage SourceFile="A.msi" />
> > <RollbackBoundary Vital="No"/>
> > <MsiPackage SourceFile="Fail.msi" /> </Chain> In this example, my
> > impression is that because the failure happened on a vital package
> > in a non-vital rollback boundary, that the bundle would be
> > considered installed and that Fail MSI would have its package cache cleared.
> >
> > (2)<Chain DisableRollback="Yes">
> > <MsiPackage SourceFile="A.msi" />
> > <MsiPackage SourceFile="Fail.msi" /> </Chain> In this example, I am
> > expecting the A MSI to remain, and the Fail MSI to just have its
> > cache cleared.
> >
> > (3)<Chain>
> > <MsiPackage SourceFile="A.msi" />
> > <MsiPackage SourceFile="Fail.msi" /> </Chain>
> > In this example, I would expect both MSI's to be
> > removed, and their caches purged.
> >
> > (4)<Chain>
> > <MsiPackage SourceFile="A.msi" />
> > <RollbackBoundary/>
> > <MsiPackage SourceFile="Fail.msi" /> </Chain>
> > In this example, is this RollbackBoundary ignored
> > because it has the same attributes as the default boundary? Meaning
> > if this chain was installing, a failure would cause A to be
> > uninstalled, and both to have their caches cleared?
> >
> > (5)<Chain>
> > <RollbackBoundary Vital="No"/>
> > <MsiPackage SourceFile="A.msi" />
> > <MsiPackage SourceFile="Fail.msi" Vital="No" />
> > <RollbackBoundary Vital="Yes">
> > <MsiPackage SourceFile="SecondFail.msi" /> </Chain>
> > In this example, A would get installed, Failed would
> > be attempted, but then ignored due to the Packages Vital state (but
> > the cache should be cleared), Followed by the SecondFail triggering
> > a rollback of everything?
> >
> > Thanks,
> > Jacob
> >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/ ______________________________
> > ______________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-devs
mailing list