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

Wed May 5 16:26:33 PDT 2021

I'm completely fine keeping that undocumented.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Wednesday, 5 May, 2021 18:59
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

He doesn't have a draft PR for dutil. But the code in Burn is calling it.

Yes, if this is the direction we want to go then the types could be stored separately. I don't know if there's value in trying to make it available, maybe just store it in an undocumented binary format in the default value for the registry key.

On Wed, May 5, 2021 at 5:55 PM Bob Arnson <bob at firegiant.com> 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> 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>
> Cc: Sean Hall <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, 
> the link is at 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> 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> 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>
> > Cc: Sean Hall <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> 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> 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>; Ron Martin <cpuwzd at comcast.net>
> > > Cc: Rob Mensching <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> On Behalf 
> > > Of Hoover, Jacob via wix-devs
> > > Sent: Tuesday, May 4, 2021 10:02 AM
> > > To: Ron Martin <cpuwzd at comcast.net>; wix-devs < 
> > > wix-devs at lists.wixtoolset.org>
> > > Cc: Hoover, Jacob <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>
> > > Sent: Tuesday, May 4, 2021 11:51 AM
> > > To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; wix-devs < 
> > > wix-devs at lists.wixtoolset.org>
> > > 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> 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.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
> > > 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/
> > >
> > ____________________________________________________________________
> > 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/