[wix-users] Bundle cache location & self-update

[Hoover, Jacob]

You could property drive a MSI at the end of the chain to do the modifications, along with the remember me pattern to persist those values that are passed in.

As well, if these sub packages are making changes that you need to be aware of, the trailing MSI could have a CA written to read those values and respond appropriately.

Modifying machine state from a BA is “bad”.

From: Jacques Eloff [mailto:repstosd at gmail.com]
Sent: Monday, June 17, 2019 4:22 PM
To: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Cc: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Bundle cache location & self-update

Hi Jacob

It's a managed BA. I'll take a look at the link. Luckily this is always a per-machine install, so per-user won't factor into anything.
I know that modifying the state is not ideal, but this is on par with something like the finalizer process that Visual Studio runs at the end of setup and gathers information from various MSIs that were installed (or not installed) to configure a product. The individual installers don't have all the information as some of it can only be determined once all or a subset of the installers have been installed, which leaves it to the bundle as the only source of truth that has knowledge of every individual installer. I could do the finalizer as an ExePackage that just executes at the end, then at least I don't have to worry about elevation.

Jacques


On Mon, Jun 17, 2019 at 1:52 PM Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>> wrote:
Bundles don't modify the state of the machine, installers do.

Also don't forget that Per-User vs Per-Machine bundles behave differently.

What are you doing by creating a shortcut to point back to the bundle?

Also, are you doing a native or managed BA?  You might find this helpful if you are doing a native one.  https://github.com/jchoover/wix3/blob/Gfc/src/ext/BalExtension/wixstdba/WixStandardBootstrapperApplication.cpp

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>] On Behalf Of Jacques Eloff via wix-users
Sent: Monday, June 17, 2019 3:27 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
Cc: Jacques Eloff <repstosd at gmail.com<mailto:repstosd at gmail.com>>
Subject: [wix-users] Bundle cache location & self-update

Hi

From what I can tell, the cache location of the bundle seems to be %ProgramData%\Package Cache\{GUID} where GUID appears to be WixBundleProperties/@Id

I have a shortcut that launches the bundle using the aforementioned path and pass additional arguments to my bundle.

However, if the bundle leverages the app syndication update mechanism and is auto-updated, Burn will download the new bundle, close the old running copy and restart the new copy.

Since there's no guarantee the user will complete an action (Install, Modify, etc.) when the updated copy is launched, is it ok to update the shortcut at the end of DetectComplete? This would ensure it launches the new bundle the next time the user runs from the shortcut.

Normally I'd create/update the shortcut at the end of ApplyComplete, but that won't fire if the user exits. It's simple enough to compare the bundle registration code of the old and currently executing bundle to figure out whether I'm in this state. Unless there's a better way to determine this.
AFAIK, there's nothing to tell me that the bundle was launched as the result of an update operation.

The only alternative I think is to keep launching the old version using the shortcut, have it auto update and continue to do this until the user completes an operation that results in Engine.Apply being called and then update the shortcut.

Thanks,
Jacques

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.
NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.