[wix-devs] WIXBUG5750 and RollbackBoundary

[Hoover, Jacob]

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/