[wix-devs] Bundles, persisted variables, and newer bundles

Bob Arnson bob at firegiant.com
Wed Oct 25 19:52:12 PDT 2017

Pretty sure there's a feature request to allow related bundles access to each other's persisted variables.

Yep, nice and fresh: https://github.com/wixtoolset/issues/issues/3704 

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Wednesday, 25 October, 2017 19:56
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-devs] Bundles, persisted variables, and newer bundles

Another option would be to extend the current Variable to allow for an additional attribute of Registered w/ a YesNo type and have the registration in the registry persist them. Then the current butil API would allow access.

> On Oct 25, 2017, at 4:22 PM, Hoover, Jacob via wix-devs <wix-devs at lists.wixtoolset.org> wrote:
>  What is the preferred way of accessing saved variable state from an existing installed bundle if the user has downloaded a newer bundle? For example, if I had a persistent burn variable, that was modifiable via the options page in WixStdBA, and it controlled "something" downstream. If the user is installing v1 of our bundle, they may customize the variables value.  When they go to install v2, I would like for the customization from v1 to be read in by v2, so the user doesn't have to re-configure the application every time they upgrade.
> If I was writing my own BA I know I could write code to persist this to the machine, but that would violate the rules that a BA shouldn't modify state (only installers should). I could pass the state into my applications main MSI, and have it persist this information in a known location, but then the application installer is taking on a role of managing the bundles state which doesn't seem right.
> Should I even consider trying to poke into the existing rsm files in the cache for the detected package? In order to do so we would likely need to do a version check to ensure that the format of the state isn't incompatible from bundle to bundle over time with differing versions of WiX.
> What I am pondering is given a bundle Id, we should expose an API that can read the state of that bundle.  I know the BA / BAF would have to subscribe to OnDetectRelatedBundle / OnDetectComplete, and from there call the API for whatever criteria they have. I wouldn't want this API to modify my state. I am thinking if I added a BURN_VARIABLES* to BURN_RELATED_BUNDLE, and then on IBootstrapperEngine add methods for GetRelatedBundleVariableString / GetRelatedBundleNumeric.  In the engine, where those methods are implemented we would lazy load variables, so only if you asked for a bundles variables, would we make the attempt to parse out the state data into a private collection of related bundle specific variables.
> Thoughts?
> Thanks,
> Jacob
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/

More information about the wix-devs mailing list