[wix-devs] WIXBUG5750 and RollbackBoundary

Tue Jan 23 09:42:42 PST 2018

And remember the *other* reason Burn registers ARP immediately: So there's *something* if a package triggers a mid-chain reboot. For that, you can't really delay registration (for .NET, e.g.) but make de-registration possible.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, 23 January, 2018 12:31
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 don't know how to reconcile what you're seeing with https://github.com/wixtoolset/issues/issues/4822/ (one of the few issues where Rob, Bob, and I have all commented)

On Tue, Jan 23, 2018 at 11:18 AM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> Strange one here...
>
>                 <Chain ParallelCache="no">
>                         <MsiPackage SourceFile="..\SecondPackage\bin\Debug\SecondPackage.msi"
> Name="payload\second\SecondPackage.msi" Compressed="no" Permanent="yes"
> Visible="yes" />
>                         <RollbackBoundary />
>                         <MsiPackage SourceFile="..\FailingPackage\bin\Debug\FailingPackage.msi"
> Name="payload\failing\FailingPackage.msi" Compressed="no" />
>                 </Chain>
>
> This I think is what Rob was speaking of.  When this chain is ran, the 
> permanent package gets installed, then the failure happens, and we do 
> indeed remove ARP. However, I see nothing different if I remove the 
> rollback boundary, that is until I add my logic for cleaning the cache 
> on rollback.
>
> Do we do some magic to the chain to do all permanent packages first?
>
> -----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 11:00 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
>
> That's not the default behavior, though. If you set Permanent to yes 
> and your stuff fails, then the bundle stays registered in ARP. I know 
> I've seen multiple people complain about this on Stack Overflow and/or wix-users.
>
> On Tue, Jan 23, 2018 at 10:55 AM, Rob Mensching <rob at firegiant.com> wrote:
>
> > There is (should be) code in there (unless my memory is totally 
> > wrong) that flips the "retain ARP entry" bit after all permanent 
> > packages are installed. Actually, writing that makes me think maybe 
> > that doesn't require a rollback boundary and we just made it the 
> > default behavior (since RollbackBoundaries weren't really discoverable).
> >
> > 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:53 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
> >
> > Interesting. I think I've only tried the Permanent=yes for .NET. I 
> > didn't realize that putting a RollbackBoundary between it and "all 
> > my stuff" would allow the bundle to unregister itself if "all my stuff"
> failed.
> >
> > On Tue, Jan 23, 2018 at 10:47 AM, Hoover, Jacob via wix-devs < 
> > wix-devs at lists.wixtoolset.org> wrote:
> >
> > > As for 1), this is not the case for any way I've tried to author it.
> > > As soon as the RollbackBounday is hit it stops rolling back. So 
> > > your bundle stays in ARP, and just .Net remains installed. If you 
> > > wanted to accomplish this, one would have to add @Permanent=yes 
> > > (this is what our .Net packages do), though that then means an 
> > > uninstall won't touch
> > it.
> > >
> > > -----Original Message-----
> > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> > > Behalf Of Rob Mensching via wix-devs
> > > Sent: Tuesday, January 23, 2018 10:38 AM
> > > To: WiX Toolset Developer Mailing List 
> > > <wix-devs at lists.wixtoolset.org>
> > > Cc: Rob Mensching <rob at firegiant.com>
> > > Subject: Re: [wix-devs] WIXBUG5750 and RollbackBoundary
> > >
> > > 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?
> > ____________________________________________________________________
> > 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/