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

Wed Jul 1 10:38:23 PDT 2020

1. The idea of an "In-progress ARP name" is interesting independent of all of this. If named well, it could help explain the ARP entry when the bundle exited unexpected.

2. The "worst case" user scenario IMHO is the user that started the product install, restarted due to .NET Framework pre-req then decides to cancel the product install. That is the case where I can clearly see why people don't want any part of the product remaining.

3. I'm not sure there is much Burn can do to protect itself from a poorly designed BA. We purposefully give significant control to the BA. At the same time, it's ideal if Burn generally does the right thing when the BA doesn't override behavior (i.e. the Burn recommendations are right)

That is why I wondered if an extra parameter passed in via RunOnce could inform the engine that by default, if the BA exits without execution (or if execution fails) the ARP entry and cache should be cleaned up as if this was a "first time install" (even though pre-req(s) was(were) already installed and required a restart).

Correct me if I'm wrong as I thought the Burn engine would have to help the BA in some way.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Tuesday, June 30, 2020 7:25 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

I guess a different way to do this would be to add the ability to author an alternative ARP DisplayName. So the normal one could be "My Bundle", and the alternative one could be "My Bundle Prerequisites". Burn would use the alternative DisplayName (if provided) when initially creating the ARP entry, and then would update the ARP entry with the normal one once a non-permanent package was installed.

This way, there's still an ARP entry tied to the cached bundle. But the user isn't led to believe the installation is complete because the alternative ARP DisplayName should make it clear that the actual application hasn't been installed yet.

On Wed, Jul 1, 2020 at 9:26 AM Sean Hall <r.sean.hall at gmail.com> wrote:

> This new design would only leave detritus on the computer if the BA 
> doesn't clean up. So unless we start allowing Burn to do real work 
> without involving the BA, adding command line parameters wouldn't 
> help. Also remember that the ARP entry isn't supposed to exist, we 
> should only be concerned about cleaning the cache.
>
> Making the elevated engine automatically clean up based on a 
> command-line parameter is possible, assuming that Burn shuts down 
> cleanly (so we're still relying on a well-behaved BA).
>
> On Wed, Jul 1, 2020 at 3:24 AM Bob Arnson via wix-devs < 
> wix-devs at lists.wixtoolset.org> wrote:
>
>> +1
>>
>> -----Original Message-----
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
>> Rob Mensching via wix-devs
>> Sent: Tuesday, 30 June, 2020 13:23
>> 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
>>
>> Would it help if there was an additional command-line argument 
>> registered with RunOnce when all packages planned were permanent?
>>
>> Then post-restart the run-once'd elevated Bundle would know if the 
>> cached bundle and ARP should be removed if no execution happens (and 
>> possible modify planning so execution removes ARP entry on failure).
>>
>> Bob's "registry cleaners" comment comes down to the fact that we 
>> really don't want to have a design that says, "Registry cleaners are 
>> useful for cleaning up the cache because we made a design decision 
>> that leaves behind detritus on your computer".
>>
>> -----Original Message-----
>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
>> Sean Hall via wix-devs
>> Sent: Sunday, June 28, 2020 3:19 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
>>
>> If it weren't for the reboot, then yes Burn could automatically 
>> uncache at the end of Apply.
>>
>> In the reboot scenario, no. Burn would have to rely on the BA to 
>> uncache if the user cancels. "Registry cleaners" are already 
>> incorrectly blowing away Burn packages in the cache so I don't think 
>> that makes a difference here.
>>
>> On Mon, Jun 29, 2020 at 8:00 AM Bob Arnson <bob at firegiant.com> wrote:
>>
>> > Could the bundle not trigger an uncache? If not, it's a nonstarter:
>> > Leaving cache behind is how "registry cleaners" start to 
>> > legitimately target Burn and make everyone's life miserable.
>> >
>> > -----Original Message-----
>> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
>> > Sean Hall via wix-devs
>> > Sent: Sunday, 28 June, 2020 17:33
>> > 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
>> >
>> > No, it doesn't need to be registered in ARP for anything but 
>> > allowing the user to remove the bundle from the cache. The bundle 
>> > can be run from the RunOnce key after the reboot without having an 
>> > ARP entry. But it does need to stay in the cache. For security, the 
>> > RunOnce key must point to the cached bundle. There's no way to do 
>> > automatic uncache in
>> this scenario.
>> >
>> > On Mon, Jun 29, 2020 at 6:39 AM Bob Arnson <bob at firegiant.com> wrote:
>> >
>> > > It needs to register and be cached to restart on reboot, right? 
>> > > If all packages are permanent and not cached, then automatic 
>> > > unregiration/uncache seems reasonable.
>> > >
>> > > -----Original Message-----
>> > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf 
>> > > Of Sean Hall via wix-devs
>> > > Sent: Sunday, 28 June, 2020 07:17
>> > > To: WiX Toolset Developer Mailing List 
>> > > <wix-devs at lists.wixtoolset.org>
>> > > Cc: Sean Hall <r.sean.hall at gmail.com>
>> > > Subject: [wix-devs] 4822 - Delay ARP registration in Bundles 
>> > > until a non-permanent package is installed
>> > >
>> > > I'm interested in implementing
>> > > https://github.com/wixtoolset/issues/issues/4822. This is the 
>> > > hard scenario that needs to be solved:
>> > >
>> > > 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 bundle updates the RunOnce key to resume after the reboot.
>> > > 8. The user allows the prereq BA to reboot the machine.
>> > > 9. RunOnce starts the bundle elevated.
>> > >
>> > > Because RunOnce always starts the target program elevated, we 
>> > > need to cache the bundle into the package cache (or other 
>> > > protected area) to be secure.
>> > > In order to allow the user to clean up their machine, we are 
>> > > registering in ARP to give them a way to clean the cache.
>> > >
>> > > If we want to implement this feature, I think we're going to have 
>> > > to allow the possibility of the bundle being cached without an ARP entry.
>> > > Either Burn removes the ARP registration somewhere between 6 and 
>> > > 8, or it never registers in the first place (because all planned 
>> > > packages are
>> > permanent).
>> > > Is this acceptable or is this feature not possible?
>> > > _________________________________________________________________
>> > > ___ WiX Toolset Developer Mailing List provided by FireGiant 
>> > > http://www.firegiant.com/
>> > >
>> > ___________________________________________________________________
>> > _ WiX Toolset Developer Mailing List provided by FireGiant 
>> > http://www.firegiant.com/
>> >
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant 
>> http://www.firegiant.com/ 
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant 
>> http://www.firegiant.com/ 
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant 
>> http://www.firegiant.com/
>>
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/