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

[Sean Hall]

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