[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles

Bob Arnson bob at firegiant.com
Thu May 6 11:59:43 PDT 2021 

Yeah, enumeration would be nice to keep around...

:squirrel emoji:

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Thursday, 6 May, 2021 14:14
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] WIXBUG3704 - Allow access to persisted variables from related bundles

I liked the idea that everything is stored in REG_SZ and the storage of types are an implementation detail that is undocumented and subject to change. This allows the original bundle to access its own persisted variables with type information, but requires everybody else to read it as a string. The engine APIs could and should coerce that string just like it does today with the existing variable methods.

This means that how the types are stored is up to you. I thought that it would be easiest to store it in binary format in the default value of the registry key, basically the existing format but leave out the actual values. I thought that the idea of having two values for every variable would make it difficult to enumerate them.

For BURN_VARIANT_TYPE_NONE, I'd have to dig into the code. My initial thought is that there should be no value written for a variable with type NONE. An empty string might work the same.

On Thu, May 6, 2021 at 12:36 PM Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> So for each variable, a REG_SZ Value for the variable, and a REG_DWORD 
> Value for the type?  Would you be opposed to having 2 keys?  IE, 
> BURN_REGISTRATION_REGISTRY_UNINSTALL_KEY\%BUNDELID%\variables\type
> and BURN_REGISTRATION_REGISTRY_UNINSTALL_KEY\%BUNDELID%\variables\value.
>
>
>
> That would allow a simple enum of the values without an additional 
> comparison on the values name.
>
>
>
> How would you propose handling REG_NONE/BURN_VARIANT_TYPE_NONE?
>
> Are we required to store BURN_VARIANT_TYPE_NUMERIC As a string, or 
> could it be persisted as a REG_QWORD?
>
>
>
> *From:* wix-devs <wix-devs-bounces at lists.wixtoolset.org> *On Behalf Of 
> *Sean Hall via wix-devs
> *Sent:* Thursday, May 6, 2021 12:24 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] WIXBUG3704 - Allow access to persisted 
> variables from related bundles
>
>
>
> I think storing each variable in a value as type REG_SZ with the 
> variable types stored separately is simple and easy and enables 
> outside use. Do you agree?
>
> On Thu, May 6, 2021 at 12:10 PM Bob Arnson <bob at firegiant.com> wrote:
>
> > If the values are trivial to read (e.g., with RegistrySearch) then 
> > it's trivial to handle across versions. I don't want to have to 
> > maintain multiple versions of de-persisting variables but not being 
> > able to
> upgrade
> > your version of WiX ever without losing that feature? That's not 
> > good. So make it simple. KISS.
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> > Sean Hall via wix-devs
> > Sent: Thursday, 6 May, 2021 13:06
> > 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] WIXBUG3704 - Allow access to persisted 
> > variables from related bundles
> >
> > I have never understood the idea that we will support a bundle being 
> > able to get any other bundle's persisted variables, but somehow have 
> > the
> ability
> > to change how we actually do that. Once you ship a bundle, it's out 
> > in
> the
> > world. It will persist its variables according to the version of 
> > Burn it was built with. If the format changes later, newer bundles 
> > won't be able
> to
> > access its persisted variables. I must be missing something.
> >
> > On Thu, May 6, 2021 at 11:56 AM Bob Arnson via wix-devs < 
> > wix-devs at lists.wixtoolset.org> wrote:
> >
> > > When this first came up, I said something along the lines of “if 
> > > it’s easy to store the variables in registry values, then we 
> > > should do that because it enables outside use.” Key is “if it’s 
> > > easy” – enabling outside use isn’t a requirement, just a nice bonus.
> > >
> > > From: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > > Sent: Thursday, 6 May, 2021 12:19
> > > To: WiX Toolset Developer Mailing List 
> > > <wix-devs at lists.wixtoolset.org>; Bob Arnson <bob at firegiant.com>
> > > Cc: Ron Martin <cpuwzd at comcast.net>
> > > Subject: RE: [wix-devs] WIXBUG3704 - Allow access to persisted 
> > > variables from related bundles
> > >
> > > One could go to the opposite end of the spectrum and say let’s 
> > > just store the existing variable blob as a single binary value. 
> > > The format remains undocumented, and the only way you access it is via DUtil.
> > >
> > > Asking for API’s in other languages/frameworks is a bit off putting.
> > > If you are installed by a bundle, you are using a Managed/Native BA.
> > > You have the ability at install/maint/removal to get previous 
> > > install
> > variables.
> > > The goal isn’t to store the applications configuration and provide 
> > > an API for any application to access it, its to allow a bundle’s 
> > > config to be persisted across reboots, and to allow bundle v 1.1 
> > > to read in what options the user chose when they installed bundle v 1.0.
> > >
> > >
> > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Ron Martin via
> > > wix-devs
> > > Sent: Thursday, May 6, 2021 12:26 AM
> > > To: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>; WiX 
> > > Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:
> <wix-devs at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs at lists.wixtoolset.org>>
> > > Cc: Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net>>
> > > Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted 
> > > variables from related bundles
> > >
> > > That's what I'm suggesting. It's more in keeping with the way the 
> > > registry is designed to be used.
> > >
> > > In the following, when I refer to an unspecified app, you should 
> > > be thinking that this "app" is Wix. I'm trying to leave as many 
> > > options open as I can think of, so don't be thinking, "We don't 
> > > need this generality in Wix". Think of using only as much as you 
> > > need. Just keep in mind that if the situation changes, these 
> > > options can still be used.
> > >
> > > The usual situationis that you have a name, consisting of a base 
> > > path plus the relative path to the registry key. Once you access 
> > > the key,you can get as many attributes as are useful. One (or 
> > > more) of the attributes can be used to store the app-specific type 
> > > of the value (or
> > > values) stored. The value, as a function of the app-specific type, 
> > > can be stored in one (or more) attributes. The registry value 
> > > types to be used for each attribute are determined by contract and 
> > > can be dependent on the values of other attributes. The contract 
> > > can be as simple or as complex as necessary to do the job at hand. 
> > > It can specify the use and method of use of versioning, whether 
> > > values can be stored in multiple app-specific types simultaneously 
> > > or only one at a time.
> > >
> > > Conversions are ultimately the responsibility of the reader. A 
> > > helper may be provided in C for convenience.
> > > Its source code can serve as a guide for readers written in other 
> > > languages.
> > >
> > > This is what I meant. Take it for what its worth. I can flesh it 
> > > out some more if your imagination hasn't already run away with you.
> > >
> > > Ron
> > >
> > >
> > > On 5/5/2021 10:24 PM, Bob Arnson wrote:
> > > > Just to clarify, you're saying each variable should have two 
> > > > registry
> > > values, one with the variable's value and one with its type?
> > > >
> > > > -----Original Message-----
> > > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Ron Martin via
> > > wix-devs
> > > > Sent: Wednesday, 5 May, 2021 19:37
> > > > To: Bob Arnson via wix-devs <wix-devs at lists.wixtoolset.org<mailto:
> <wix-devs at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs at lists.wixtoolset.org>>
> > > > Cc: Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net>>
> > > > Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted 
> > > > variables
> > > from related bundles
> > > >
> > > > Perhaps a little less fugly would be to use two different values 
> > > > of the
> > > same registry key (say, for sake of argument, "Type" and "Value"), 
> > > so that a single name applies to both. You could even add a "Version"
> > > value to the mix, but I'd lean toward versioning the names of the 
> > > types ("Version.V1", "Version.V2", perhaps) if a new direction is
> > desirable in the future.
> > > >
> > > > Ron
> > > >
> > > > On 5/5/2021 6:55 PM, Bob Arnson via wix-devs wrote:
> > > >> I don’t see any dutil changes in Jacob's repos or draft PRs on
> > > wixtoolset...
> > > >>
> > > >> As I didn't know a variable's type could be changed, it's 
> > > >> obviously not important (or I would've known, right?!). 😊
> > > >>
> > > >> We could always store the variable values in individual REG_SZ 
> > > >> values
> > > then encode their types separately. E.g.: _BurnVariables (REG_SZ) 
> > > = "Var1=0;Var2=1;Var3=2".
> > > >>
> > > >> Fugly but effective.
> > > >>
> > > >> -----Original Message-----
> > > >> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > > >> Sean Hall via wix-devs
> > > >> Sent: Wednesday, 5 May, 2021 18:09
> > > >> To: WiX Toolset Developer Mailing List 
> > > >> <wix-devs at lists.wixtoolset.org
> <wix-devs at lists.wixtoolset.org%0b>> > < 
> mailto:wix-devs at lists.wixtoolset.org <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] WIXBUG3704 - Allow access to persisted 
> > > >> variables from related bundles
> > > >>
> > > >> Since this always happens when we send this amount of mail in 
> > > >> one day -
> > > you can unsubscribe from this list by sending an email with the 
> > > subject "Unsubscribe" to wix-devs-unsubscribe at lists.wixtoolset.org
> > <mailto:
> <%0b>> > wix-devs-unsubscribe at lists.wixtoolset.org>, the link is at
> > > https://wixtoolset.org/documentation/mailinglist/<
> > > https://wixtoolset.org/documentation/mailinglist>.
> > > >>
> > > >> 2. No, I was assuming Jacob's existing dutil API. If they're 
> > > >> all
> > > persisted as strings, then the dutil API could be changed to only 
> > > return strings.
> > > >>
> > > >> But only storing them as strings depends on 1. The engine needs 
> > > >> to know
> > > the types, and if the type isn't stored with the persisted 
> > > variables then it would have to restrict the variable from 
> > > changing its type from the manifest.
> > > >>
> > > >> On Wed, May 5, 2021 at 4:54 PM Bob Arnson <
> bob at firegiant.com<mailto:
> <bob at firegiant.com%3cmailto:%0b>> > bob at firegiant.com>> wrote:
> > > >>
> > > >>> 1. Didn’t know that was a thing, so I have no opinion on 
> > > >>> whether that's a good/bad/indifferent restriction.
> > > >>> 2. Does dutil need to care? BundleGetBundleInfo returns only 
> > > >>> strings today, so I'd assume that'd be good enough for non-BA 
> > > >>> users. BAs could request explicit types and we haven't 
> > > >>> discussed any kind of authoring level of support for this feature.
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > > >>> Sean Hall via wix-devs
> > > >>> Sent: Tuesday, 4 May, 2021 15:33
> > > >>> To: WiX Toolset Developer Mailing List 
> > > >>> <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolse
> > > >>> t.or
> <wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or%0
> b>>
> > >>> g>>
> > > >>> Cc: Sean Hall
> > > >>> <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>
> > > >>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted 
> > > >>> variables from related bundles
> > > >>>
> > > >>> That would require that persisted variables can't have their 
> > > >>> type dynamically changed at runtime. Maybe this is reasonable, 
> > > >>> but it's a restriction that doesn't exist today.
> > > >>>
> > > >>> That doesn't really work when querying outside of the original
> > bundle.
> > > >>> I think it can be argued that the querier should be required 
> > > >>> to ask for a specific type instead of tracking it in the 
> > > >>> registry, but that would require the dutil API to know how to 
> > > >>> do Burn
> variable
> > coercion.
> > > >>>
> > > >>> On Tue, May 4, 2021, 14:17 Bob Arnson via wix-devs < 
> > > >>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset
> > > >>> .org
> > > >>> >>
> > > wrote:
> > > >>>
> > > >>>> BAs already have to specify a type when getting a variable 
> > > >>>> value from the engine. The engine knows a variable's type 
> > > >>>> when it persists the value -- so what if it required a 
> > > >>>> variable to exist so it had the type
> > > >>> when reading it?
> > > >>>> At that point, the registry type could be REG_SZ for 
> > > >>>> everything, no encoding necessary.
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > > >>>> Rob Mensching via wix-devs
> > > >>>> Sent: Tuesday, 4 May, 2021 14:13
> > > >>>> To: WiX Toolset Developer Mailing List 
> > > >>>> <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtools
> > > >>>> et.o
> <wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o%0b
> >>
> > >>>> rg>>;
> > > Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net>>
> > > >>>> Cc: Rob Mensching 
> > > >>>> <rob at firegiant.com<mailto:rob at firegiant.com>>
> > > >>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to 
> > > >>>> persisted variables from related bundles
> > > >>>>
> > > >>>> Sorry, I mentioned encoding the values in a string the way 
> > > >>>> the Windows Installer does in the Registry table to include 
> > > >>>> it as an option. I do not have a strong opinion that it is 
> > > >>>> the best way to go (although encoding in JSON or XML seems 
> > > >>>> way overkill). Trying to reuse the built-in registry types is 
> > > >>>> noble if you can resolve all the issues Sean
> > > >>> was discussing.
> > > >>>> -----Original Message-----
> > > >>>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> > 
> wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of
> > > >>>> Hoover, Jacob via wix-devs
> > > >>>> Sent: Tuesday, May 4, 2021 10:02 AM
> > > >>>> To: Ron Martin 
> > > >>>> <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net>>;
> > > wix-devs <
> > > >>>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolse
> > > >>>> t.or
> > > >>>> g>>
> > > >>>> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <Jacob.Hoover at greenheck.com%3cmailto:%0b>> > 
> Jacob.Hoover at greenheck.com>>
> > > >>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to 
> > > >>>> persisted variables from related bundles
> > > >>>>
> > > >>>> Unrecognized types? The engine only supports a fixed set of types.
> > > >>>> Extensions can’t define additional variable types.
> > > >>>>
> > > >>>> “Much easier” is an opinion.
> > > >>>>
> > > >>>> If we really want to go the string route, why not use a JSON 
> > > >>>> object in the registry? We could then define it’s type and 
> > > >>>> value, still live as a string, and have a well defined 
> > > >>>> structure to validate
> > > against.
> > > >>>>
> > > >>>> From: Ron Martin 
> > > >>>> <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net>>
> > > >>>> Sent: Tuesday, May 4, 2021 11:51 AM
> > > >>>> To: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <Jacob.Hoover at greenheck.com%3cmailto:%0b>> > 
> Jacob.Hoover at greenheck.com>>; wix-devs <
> > > >>>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolse
> > > >>>> t.or
> > > >>>> g>>
> > > >>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to 
> > > >>>> persisted variables from related bundles
> > > >>>>
> > > >>>>
> > > >>>> Some of the things I thought about before making my suggestion:
> > > >>>>
> > > >>>> If all of the strings we store in the registry (in this 
> > > >>>> context) are differentiated by their first character, many 
> > > >>>> new types can be added later if necessary. A single switch 
> > > >>>> statement can be used to separate
> > > >>> the type.
> > > >>>> Unrecognized types can be passed through extensions.
> > > >>>>
> > > >>>> The registry was not designed for flexibility or extensibility.
> > > >>>> Binary data can be organized for straight-forward decoding, 
> > > >>>> just as string data, but for debugging purposes, it is much 
> > > >>>> easier to decode strings than raw binary representation of 
> > > >>>> multiple data
> > structures.
> > > >>>>
> > > >>>> Registry strings should not be used to store binary data in 
> > > >>>> its raw form because there is a potential for truncation when 
> > > >>>> a null character is encountered. Registry strings are 
> > > >>>> constrained to
> > > >>>> UTF-16 with no encoding prefix.
> > > >>>>
> > > >>>> Ron
> > > >>>> On 5/4/2021 11:27 AM, Hoover, Jacob wrote:
> > > >>>> easier to handle.
> > > >>>>
> > > >>>> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:
> <wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>> >
> wix-devs-bounces at lists.wixtoolset.org>><mailto:
> > > <mailto:%0b <%0b>>>>>> wix-devs-bounces at lists.wixtoolset.org<mailto:
> > > wix-devs-bounces at lists.wixtoolset.org>> On Behalf Of Ron Martin 
> > > via
> > > >>>> wix-devs
> > > >>>> Sent: Friday, April 30, 2021 2:49 PM
> > > >>>> To:
> > > >>>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolse
> > > >>>> t.or
> > > >>>> g
> > > <mailto:wix-devs at lists.wixtoolset.org%
> <wix-devs at lists.wixtoolset.org%25%0b>> > 
> 3cmailto:wix-devs at lists.wixtoolset.org>>
> > > >>>> Cc: Ron Martin <cpuwzd at comcast.net<mailto:cpuwzd at comcast.net
> <cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b>> > >>< 
> mailto:cpuwzd at comcast.net <cpuwzd at comcast.net>>
> > > >>>> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to 
> > > >>>> persisted variables from related bundles
> > > >>>> 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/<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/
> > > > ________________________________________________________________
> > > > ____ WiX Toolset Developer Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> > > __________________________________________________________________
> > > __ WiX Toolset Developer 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.
> > > __________________________________________________________________
> > > __ 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/
>
> 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/

More information about the wix-devs mailing list