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

[Sean Hall]

> 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.
> > >
> > >
>