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

Fri Dec 11 16:01:06 PST 2020

It was too confusing discussing this as a single issue so I split it up.

On Wed, Aug 5, 2020 at 1:34 PM Bob Arnson <bob at firegiant.com> wrote:

> I'm somewhat a subject matter expert, have read the WIP, and reread the
> whole thread and I have only the barest outline of the point of contention.
>
> I believe these are not in dispute; do you agree?
>
> 1. #4822 *AS WRITTEN* cannot be completely fixed/implemented: We (seem to)
> agree that an ARP entry must be written to allow for uncaching in the event
> the BA or even Burn can't successfully uncache in the event of
> failure/cancellation.
> 2. An amelioration (not a fix because a fix is impossible) for #4822 is to
> use an "in-progress" name for the ARP entry and to attempt to uncache in
> the event of failure/cancellation.
>
> The only thing I think is unclear is how to deal with a bundle that
> contains permanent packages that aren't "installer pre-reqs."
>
> We already have PrereqSupportPackage -- is that sufficient to cover the
> (abhorrent) case of installer pre-reqs that aren't also product pre-reqs? I
> can absolutely see a use case for a permanent package being part of a
> "product" and not the installer. (Basically anything the product needs that
> some other product might use *and* presents its own ARP entry is most
> safely delivered as a permanent package.) Those would not get marked with
> PrereqSupportPackage and wouldn't "count."
>
> Are there other things I've missed?
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Wednesday, 5 August, 2020 13:41
> 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
>
> Rob, what you've been missing is I didn't need help coming up with a
> solution for your scenario. Every time you tried to derail the conservation
> to your scenario, I tried to bring it back to mine.
>
> Jacob, that scenario is supposed to be covered in part 2 of the WIP.
>
> What I'm hearing from both of you is that I should not have tried to group
> all of these issues in 4822 even if I'm going to fix them all at the same
> time.
>
> On Wed, Aug 5, 2020 at 11:26 AM Hoover, Jacob via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
> > This seems to relate to the discussions that Sean and I had before
> > with rollbacks.  I had a similar use case where a user could start
> > installing, hit cancel, and still have the bundle registered.
> >
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Rob Mensching via wix-devs
> > Sent: Wednesday, August 5, 2020 10:02 AM
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Rob Mensching <rob at firegiant.com>
> > Subject: Re: [wix-devs] 4822 - Delay ARP registration in Bundles until
> > a non-permanent package is installed
> >
> > 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-25577231
> > 2<
> > https://github.com/wixtoolset/issues/issues/4822#issuecomment-25577231
> > 2>
> >
> > > 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-25579909
> > 3<
> > https://github.com/wixtoolset/issues/issues/4822#issuecomment-25579909
> > 3>
> >
> > > 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<mailto:
> > 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
> > <mailto:wix-devs at lists.wixtoolset.org>>
> > Cc: Sean Hall <r.sean.hall at gmail.com<mailto: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<mailto:
> > 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<mailto:
> > 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
> > <mailto:wix-devs at lists.wixtoolset.org>>
> > > Cc: Sean Hall <r.sean.hall at gmail.com<mailto: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
> <mailto:
> > 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<mailto:
> > 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<mailto:wix-devs at lists.wixtoolset.or
> > > > g>>
> > > > Cc: Sean Hall
> > > > <r.sean.hall at gmail.com<mailto: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
> > <mailto: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<mailto:
> > 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<mailto:wix-devs at lists.wixtoolset.
> > > > > org
> > >>
> > > > > Cc: Sean Hall
> > > > > <r.sean.hall at gmail.com<mailto: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
> > <mailto: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/<http://www.firegiant.com>
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/<http://www.firegiant.com/>
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/<http://www.firegiant.com/>
> > NOTE: This email was received from an external source. Please use
> > caution when opening links or attachments in the message.
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>