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

Fri May 7 11:22:05 PDT 2021

I think the only concern would be that the original bundle would read the
values from the binary stream but everyone else reads the other format. I
think this is intended to be read-only anyway so it shouldn't be a problem,
but some people might be surprised that changing the string registry values
doesn't affect the original bundle.

>  we could then expand the formatted strings

I don't know what to do about this one. I understand people might want
this, but it could end up persisting the values of hidden variables.

On Fri, May 7, 2021 at 12:55 PM Hoover, Jacob via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> Would anyone have heartburn if the existing binary stream was stored in
> the registry as the default value (includes the count, included, name,
> type, value) and as an added bonus we would also store the string value of
> the persisted variables?  Doing so, we could then expand the formatted
> strings, yet retain the unformatted value in the blob.  Anything other than
> the original bundle would then use the new API to read related bundle
> variables as a string, and coerce them into their intended types.
>
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Ron
> Martin via wix-devs
> Sent: Thursday, May 6, 2021 3:04 PM
> To: wix-devs at lists.wixtoolset.org
> Cc: Ron Martin <cpuwzd at comcast.net>
> Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables
> from related bundles
>
> Good discussion!
>
> The term "related bundles" also conjures up an image of two bundles playing
> relative roles the way Reharper relates to VS. This would entail the
> ability to
> determine the registry base node of the related app (VS) by the given app
> (Resharper), perhaps via permanent GUID. This could, of course simply be
> a private agreement between the two bundled apps. But, if the installations
> can be moved around (including the registry entries) some help from Wix
> might
> be helpful. (You probably wouldn't Resharper's installer  to have to
> open an instance
> of VS in order to complete its own installation.) Remember, Resharper
> and VS are
> being used as role models here, not as concrete applications.
>
> This is a totally separate issue but it might be a desirable follow-on
> feature.
>
> Ron
>
> On 5/6/2021 2:13 PM, Sean Hall via wix-devs wrote:
>
> > 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<mailto: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<mailto:
> 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
> <mailto: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
> >>
> >>
> >>
> >> 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<mailto:
> 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<mailto:
> 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
> <mailto: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
> >>>
> >>> 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<mailto: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<mailto:
> Jacob.Hoover at greenheck.com>>
> >>>> Sent: Thursday, 6 May, 2021 12:19
> >>>> To: WiX Toolset Developer Mailing List
> >>>> <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>;
> Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>
> >>>> 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
> >>>>
> >>>> 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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%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: Thursday, May 6, 2021 12:26 AM
> >>>> To: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com<mailto:
> bob at firegiant.com%3cmailto:bob at firegiant.com>>>; WiX
> >>>> Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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<mailto:
> cpuwzd at comcast.net%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%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: Wednesday, 5 May, 2021 19:37
> >>>>> To: Bob Arnson via wix-devs <wix-devs at lists.wixtoolset.org<mailto:
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> 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<mailto:
> cpuwzd at comcast.net%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org<mailto:
> 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
> <mailto:wix-devs at lists.wixtoolset.org%0b>>> <wix-devs at lists.wixtoolset.org
> %0b<mailto:wix-devs at lists.wixtoolset.org%0b>>> > <
> >> mailto:wix-devs at lists.wixtoolset.org <wix-devs at lists.wixtoolset.org
> <mailto:wix-devs at lists.wixtoolset.org>>>>
> >>>>>> Cc: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com
> <mailto:r.sean.hall at gmail.com%3cmailto: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:wix-devs-unsubscribe at lists.wixtoolset.org>
> >>> <mailto:
> <mailto:%0b>>> <%0b>> > wix-devs-unsubscribe at lists.wixtoolset.org<mailto:
> wix-devs-unsubscribe at lists.wixtoolset.org>>, the link is at
> >>>> https://wixtoolset.org/documentation/mailinglist/<
> https://wixtoolset.org/documentation/mailinglist><
> >>>> 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<mailto:bob at firegiant.com%3cmailto>:
> >> <bob at firegiant.com%3cmailto:%0b<mailto:bob at firegiant.com%3cmailto:%0b>>>
> > bob at firegiant.com<mailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org<mailto:
> 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.wixtoolset.or
> <mailto:wix-devs at lists.wixtoolset.org
> %3cmailto:wix-devs at lists.wixtoolset.or%0b>>> <
> wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.or
> %0b<mailto:wix-devs at lists.wixtoolset.org
> %3cmailto:wix-devs at lists.wixtoolset.or%0b>>>
> >>>>>> g>>
> >>>>>>> Cc: Sean Hall
> >>>>>>> <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com<mailto:
> r.sean.hall at gmail.com%3cmailto: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
> <mailto:wix-devs at lists.wixtoolset.org%
> 3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org<mailto:
> 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.wixtoolset.o
> <mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o%0b>>>
> <wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.o
> %0b<mailto: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<mailto:
> cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>
> >>>>>>>> Cc: Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com
> <mailto:rob at firegiant.com%3cmailto: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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org<mailto:
> 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
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>;
> >>>> wix-devs <
> >>>>>>>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.or
> <mailto:wix-devs at lists.wixtoolset.org
> %3cmailto:wix-devs at lists.wixtoolset.or>
> >>>>>>>> g>>
> >>>>>>>> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>> <
> Jacob.Hoover at greenheck.com%3cmailto:%0b<mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>>
> > Jacob.Hoover at greenheck.com<mailto: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
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net>>>
> >>>>>>>> Sent: Tuesday, May 4, 2021 11:51 AM
> >>>>>>>> To: Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:
> <mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>> <
> Jacob.Hoover at greenheck.com%3cmailto:%0b<mailto:Jacob.Hoover at greenheck.com%3cmailto:%0b>>>
> > Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>>;
> >> wix-devs <
> >>>>>>>> wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.or
> <mailto:wix-devs at lists.wixtoolset.org
> %3cmailto:wix-devs at lists.wixtoolset.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:
> <mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> <
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto:%0b>>> >
> >> wix-devs-bounces at lists.wixtoolset.org>><mailto<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3e%3e%3cmailto>:
> >>>> <mailto:%0b <%0b<mailto:%0b%20%3c%0b>>>>>>>
> wix-devs-bounces at lists.wixtoolset.org<mailto<mailto:
> wix-devs-bounces at lists.wixtoolset.org%3cmailto>:
> >>>> 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.or
> <mailto:wix-devs at lists.wixtoolset.org
> %3cmailto:wix-devs at lists.wixtoolset.or>
> >>>>>>>> g
> >>>> <mailto:wix-devs at lists.wixtoolset.org%
> <mailto:wix-devs at lists.wixtoolset.org%25%0b>>> <
> wix-devs at lists.wixtoolset.org%25%0b<mailto: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
> <mailto:cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b>>> <
> cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b<mailto:
> cpuwzd at comcast.net%3cmailto:cpuwzd at comcast.net%0b>>> > >><
> >> mailto:cpuwzd at comcast.net <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/<http://www.firegiant.com><
> http://www.firegiant.com<http://www.firegiant.com>>
> >>>>>>>> _________________________________________________________________
> >>>>>>>> ___ 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/<http://www.firegiant.com/>
> >>>>>>>>
> >>>>>>> __________________________________________________________________
> >>>>>>> __ 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/<http://www.firegiant.com/>
> >>>>>> ___________________________________________________________________
> >>>>>> _ 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/<http://www.firegiant.com/>
> >>>> ____________________________________________________________________
> >>>> WiX Toolset Developer Mailing List provided by FireGiant
> >>>> http://www.firegiant.com/<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/<http://www.firegiant.com/>
> >>>>
> >>> ____________________________________________________________________
> >>> 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/<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/<http://www.firegiant.com/>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/<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/
>