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

[Sean Hall]

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