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

[Hoover, Jacob]

https://github.com/jchoover/web/blob/master/src/Web/Static/documents/development/wips/3704-sharing-bundle-variables-across-bundle-versions.html.md


-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Friday, October 27, 2017 1:23 PM
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

Still no WIP, but I pushed my roughed in implementation to https://github.com/jchoover/wix3/tree/WIXFEAT3704.

I did basic testing of a bundle installing and ensuring the variables get persisted.  Afterwards, I put together the methods for reading the values but those are 100% untested.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Thursday, October 26, 2017 7:57 PM
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

So I need to work on the WIP tomorrow, but I have a roughed in and functioning for installs/uninstalls...

    <Variable Name="InstallOptionA" Type="string" Persisted="shared" Value="Option A"/>
    <Variable Name="InstallOptionB" Type="numeric" Persisted="shared" Value="1"/>

I opted for the idea of changing the type of Persisted to a YseNoShared new custom type.


-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Rob Mensching via wix-devs
Sent: Wednesday, October 25, 2017 11:17 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Rob Mensching <rob at firegiant.com>
Subject: Re: [wix-devs] Bundles, persisted variables, and newer bundles

Sure.

Regards,

  Rob Mensching
  CEO
  FireGiant
_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

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

Topic for tomorrow? I'm kinda liking my second proposal...

Sent from my iPhone

> On Oct 25, 2017, at 9:52 PM, Bob Arnson <bob at firegiant.com> wrote:
> 
> 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/
____________________________________________________________________
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/