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

Wed Aug 5 08:02:00 PDT 2020

For #4822, I am talking about my scenario. Note that step 11 can be replaced with anything that causes the bundle to not complete successfully.

I derived my scenario from this comment in the issue: https://github.com/wixtoolset/issues/issues/4822#issuecomment-255772312

> We install .net 4.6.2 on the target machine and it is quite common that a reboot is required due to this (from our observations). Then the system reboots and the setup starts again. The user can enter all details (installation directory etc.) but when pressing on install the installer fails.

I called out cancelling in the scenario because it's a faster way to the problem, and mentioned in this common on the issue: https://github.com/wixtoolset/issues/issues/4822#issuecomment-255799093

> I cannot guarantee that not our BA is to blame that the installation fails, there might be a event or status code that we handle wrong. But considering only the cancelling approach, it is, from user perspective, already wrong that a ARP entry is created for an application that was not installed.

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

>  I'm (obviously) still holding out hope there is a solution to end up
with no ARP entry in this scenario.

I don't know which scenario you're referring to.

Sean's Scenario

1. User starts the per-machine bundle on a clean machine.
2. The bundle has an MBA and needs to install the .NET Framework.
3. The bundle caches itself into the package cache.
4. The bundle registers in ARP.
5. The bundle creates a RunOnce key.
6. The bundle installs the permanent .NET package, which requires a reboot.
7. The BA requests restart from OnPackageComplete.
8. The bundle updates the RunOnce key to resume after the reboot.
9. The user allows the prereq BA to reboot the machine.
10. RunOnce starts the bundle elevated.

Rob's Scenario

[1-10 from Sean's Scenario]
11. User cancels.
12. Bundle calls engine's Quit method.
13. Engine shuts down.

On Sat, Aug 1, 2020 at 12:48 PM Rob Mensching <rob at firegiant.com> wrote:

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