[wix-devs] 4822 - Delay ARP registration in Bundles until a non-permanent package is installed

Sat Aug 1 11:48:09 PDT 2020

> I have been designing how to handle the confusing ARP entry *at the time of restarting*. I can create a new issue for this if you want, but this is the core issue for me in 4822.

This is where I'm struggling to properly communicate. I think #4822 (and dupe'd #4905) correctly describes one of very few remaining design flaws in Burn* (fyi: another is the handling of MSI Upgrade table and another is the handling of persisted+hidden variables). I am concerned that if we say, "The solution to the errant Burn ARP entry is to change the text of the Burn ARP entry to say the bundle is 'still in-progress'" that users will argue that we have not solved the problem. These types of issues pain me even if I don't have time to dig in deep and solve them.

I'm (obviously) still holding out hope there is a solution to end up with no ARP entry in this scenario. But you are much closer to the code than I am. If you are confident there is no solution, then I think we should close #4822 with that information. I do think that creating a separate entry for "to handle the confusing ARP entry *at the time of restarting*". And if #4822 cannot be solved outright, linking the " handle the confusing ARP entry *at the time of restarting*" could be linked to it as a partial solution.

Am I still missing the point? Have I completely misunderstood #4822? It wouldn't be the first time I was completely wrong because I helicoptered into some issue.

* Arguably, this issue is in mbahost's expectations of Burn not Burn itself.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, July 29, 2020 2:22 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] 4822 - Delay ARP registration in Bundles until a non-permanent package is installed

> That's a strong statement. I thought we were throwing around ideas 
> here
to try to come up with a solution to #4822?
> Ahh, okay. Yes. That is the disconnect.

I don't know how you could have written both of these in the same email.
Can you reread the WIP I wrote? Since the beginning of this email chain, I have been designing how to handle the confusing ARP entry *at the time of restarting*. I can create a new issue for this if you want, but this is the core issue for me in 4822.

> and I don't think it needs to be tied to pre-reqs but I can see the
argument either way

I believe we could add the new concept of pre-reqs as a non-breaking change so I'll not worry about it now.

> Have I missed anything? Are there other solutions..?

I thought we've already agreed on option 2 as the solution to the issue you've been focusing on. The question I had was whether the engine should always try to clean up on Quit. And then you asked me what I meant by clean up, which I responded with cleaning the cache and removing the ARP entry.

On Wed, Jul 22, 2020 at 3:03 PM Rob Mensching <rob at firegiant.com> wrote:

> > The scenario that you've been focusing on - user cancels after
> installing NETFX caused a reboot - is a separate issue to me
>
> Ahh, okay. Yes. That is the disconnect. I took issue #4822 to 
> represent the problem called out in the linked thread and the 
> duplicated bug #4905. I didn't consider the issue's title much because 
> it was written by someone that didn't really understand how Burn 
> works. Perhaps we should fix the issues title? #4905 was pretty on the nose.
>
> > only exists because we've deemed 4822 impossible.
>
> That's a strong statement. I thought we were throwing around ideas 
> here to try to come up with a solution to #4822?
>
> > > I just don't know that having an explicit PrereqChain really buys 
> > > us
> anything.
> >
> > I gave a potential reason. I guess you didn't think it was valid.
>
> I do think "InProgressRegistrationName" is a cool feature and it would 
> better represent interrupted installations (and I don't think it needs 
> to be tied to pre-reqs but I can see the argument either way). 
> However, I am concerned about resolving #4822 with 
> "InProgressRegistrationName" because when the user cancels an 
> installation after the mbapreq is complete then the InProgressRegistrationName would be what is left in ARP.
>
> Some fundamentals:
>
> 1. ARP entry is created early in execution so there is a place to 
> "continue or undo" an interrupted (partially completed) installation 
> 2. Post-forcerestart (including mbapreq restart), bundle should resume 
> automatically post-restart 3. Bundle is cached in secure cache so 
> RunOnce can safely resume it elevated 4. Since mbapreq "partially 
> completes" successfully the cached bundle and ARP entry remain present 
> even if the user cancels or the install fails and rolls back
>
> I think we've covered the bases and there are two options:
>
> 1. BA's that use mbapreq need to plan and execute an uninstall if the 
> bundle does not execute an install successfully 2. Burn "knows" when 
> it is running post mbapreq/post-restart and cleans up the cached 
> bundle and ARP entry as the bundle exits if the bundle does not 
> execute an install successfully
>
> Have I missed anything? Are there other solutions..?
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Sean Hall via wix-devs
> Sent: Friday, July 17, 2020 9: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] 4822 - Delay ARP registration in Bundles until 
> a non-permanent package is installed
>
> > Is there a design that avoids losing the battle?
>
> In general, no. The second option I proposed in the WIP (to skip 
> writing the ARP entry and rely on the RunOnce key) relied on assuming 
> that the bundle could finish executing when run from the RunOnce key. 
> We all agreed that we couldn't make that assumption.
>
> I think we're actually discussing multiple issues here. For me, 4822 
> is explicitly about the fact that the Burn engine is writing an ARP 
> entry in the scenario described in the WIP. We've already agreed that 
> it must be written. So we've already agreed that implementing this 
> issue is impossible. So for me, the InProgressRegistrationName is our 
> mitigation for
> 4822 - instead of writing "the" ARP entry we are writing a "pre-req" 
> ARP entry.
>
> The scenario that you've been focusing on - user cancels after 
> installing NETFX caused a reboot - is a separate issue to me that only 
> exists because we've deemed 4822 impossible. It may be a common 
> scenario, but it's also pretty much the only scenario where the BA can 
> actually do the right thing without help from the engine. Like I've 
> said, I completely agree we should try to address this scenario.
>
> The other issue is that the Burn engine needs to adjust its plan such 
> that the bundle isn't cached or registered in ARP at the end of 
> execution if no non-permanent packages are present on the machine at the end of execution.
>
> >  What do you mean exactly by clean-up?
>
> Removing the ARP entry and cached bundle when there are no 
> non-permanent packages present on the machine.
>
> > I just don't know that having an explicit PrereqChain really buys us
> anything.
>
> I gave a potential reason. I guess you didn't think it was valid.
>
> On Sat, Jul 18, 2020 at 8:42 AM Rob Mensching <rob at firegiant.com> wrote:
>
> > > To me, the battle was already lost in (2) of your scenario where 
> > > the
> > bundle gets registered.
> >
> > Is there a design that avoids losing the battle (without leaving the 
> > bundle in a location that won't get cleaned up)? Fundamentally the 
> > scenario
> > is:
> >
> > 1. BA requires .NETFX
> > 2. Burn uses mbapreq to install .NETFX 3. NETFX requires restart, 
> > user restarts 4. After restart, Burn starts up BA's managed code 5. 
> > User cancels BA without starting install 6. Nothing but NETFX is 
> > left on the machine as a result of Burn
> >
> >
> > > Is there a reason that the engine needs the command line parameter 
> > > to
> > clean up after Quit? I think it should always try to clean up, and 
> > maybe we need to add a parameter to Quit to opt out of that.
> >
> > I don't quite follow. What do you mean exactly by clean-up?
> >
> >
> > > Now that you say it, I think we have been designing a "pre-req"
> > > section
> > of the chain.
> >
> > Yep. I just don't know that having an explicit PrereqChain really 
> > buys us anything.
> >
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> > Sean Hall via wix-devs
> > Sent: Wednesday, July 15, 2020 7:30 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] 4822 - Delay ARP registration in Bundles 
> > until a non-permanent package is installed
> >
> > To me, the battle was already lost in (2) of your scenario where the 
> > bundle gets registered. The user is going to see an ARP entry that 
> > they don't expect. That's why I'm much less concerned about the BA 
> > not cleaning up, it's the engine's fault of registering in the first 
> > place. I'm not against trying to help the BA clean up the bundle, I 
> > just think making that unexpected ARP entry less confusing is much 
> > more
> important.
> >
> > Is there a reason that the engine needs the command line parameter 
> > to clean up after Quit? I think it should always try to clean up, 
> > and maybe we need to add a parameter to Quit to opt out of that.
> >
> > Now that you say it, I think we have been designing a "pre-req"
> > section of the chain. The only reason I can see to make it explicit 
> > would be if somebody really wanted a permanent package to be 
> > considered part of the "real" part of the bundle. I can't see us 
> > allowing non-permanent packages in the "pre-req" section of the chain.
> > If there were a PrereqChain element, it would make more sense for 
> > the "InProgressRegistrationName" attribute to be specified there.
> >
> > On Thu, Jul 16, 2020 at 3:59 AM Rob Mensching <rob at firegiant.com> wrote:
> >
> > > > The reason I want "until first non-permanent package" is that it 
> > > > seems
> > > to be the best way to describe when a "real" part of the bundle 
> > > has been installed. If the bundle is uninstalling and it fails 
> > > before all non-permanent packages are uninstalled, then I don't 
> > > think the "InProgressRegistrationName" should ever be written to 
> > > ARP during that Apply execution.
> > >
> > > Yeah. Seems reasonable. We're really getting to a point of having 
> > > a "pre-req" section of the chain in Burn. I'm not sure it's worth 
> > > explicitly specifying in the .wxs but maybe the BurnBackend should 
> > > automatically tag early permanent packages as "pre-reqs" to help 
> > > the engine? I don't know just ideas.
> > >
> > > > Points 1 and 2 in the WIP should ensure that if the BA does
> > > Detect/Plan/Apply then the engine does the right thing. So the 
> > > only problem is if the BA doesn't successfully start Apply. That 
> > > means that any functionality we add would have to happen when they 
> > > call the engine's Quit method, and it probably would need a new 
> > > command line parameter since we shouldn't rely on the BA calling Detect.
> > > That should be possible to implement but might be tricky since the 
> > > BA has effectively shutdown and wouldn't be expecting any more
> messages.
> > >
> > > Yes. This is exactly what I was pointing out and I 100% agree with 
> > > everything you said. It isn't that hard to get into this situation:
> > >
> > > 1. Launch bundle that requires NETFX installed and restarted 2.
> > > Install NETFX, bundle will be registered, restart 3. Resume 
> > > installation, bundle shows its install UI for first time 4. User 
> > > cancels without proceeding through the install UI 5. The bundle is 
> > > still registered but the user thinks they "cancelled the install"
> > > before even clicking the Install button (they only accepted the 
> > > "NETFX install", not the "product's install")
> > >
> > > The work around *is* easy, uninstall the "leftover" product. The 
> > > problem is the perception of the user that thinks the product 
> > > never should have been there (installing NETFX isn't installing 
> > > the product). I agree the only solution I've seen is for Burn to 
> > > clean up the cached bundle and registration during Quit() without 
> > > talking to the
> > BA.
> > >
> > > My primary concern remains that the "InProgressRegistrationName"
> > > solution does not address this most problematic scenario.
> > >
> > >
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/