[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles
r.sean.hall at gmail.com
Fri Apr 30 11:00:26 PDT 2021
> but I am not sure what behavior changes assigning a string to a version
variable would cause.
The only difference is their comparison logic in conditions. I just took a
deeper look (CompareOperands in condition.cpp), and it looks like this
wouldn't work. Strings would be compared using versioning logic (or vice
versa depending on which one Burn chose). So sharing REG_SZ is a bad idea.
I'm just trying to throw out ideas that are simple to implement that don't
require throwing variables into a binary format. I think it's worth using
EXPAND_SZ for a purpose other than its intended purpose - that it signifies
unexpanded environment variables - but maybe other people feel differently.
If VERSION isn't REG_SZ, then maybe we can put it in EXPAND_SZ even though
there is nothing to expand. This would have the additional benefit that
version strings really shouldn't have '%' chars so if someone did try to
expand it there would be no change.
> why do we need to differentiate between STRING and FORMATTED?
These definitely need to be differentiated. The point of STRING is to hold
paths like C:\[pathwithbrackets]\ that don't get formatted. Given that
FORMATTED variables are expected to have unexpanded variables, there's
probably a lot less value in having them available transparently so maybe
FORMATTED should continue to be stored with REG_BINARY like you have it
On Fri, Apr 30, 2021 at 11:11 AM Hoover, Jacob wrote:
> If you don’t have a unique registry type per variable type, then on
> restore you would end up loosing that. IE, round tripping a version
> variant through the registry, on restore we would no longer know it’s a
> version, so it would get assigned as a string. I know you recently did a
> lot of rework on VERSION to support semantic versioning, but I am not sure
> what behavior changes assigning a string to a version variable would cause.
> For FORMATTED vs EXPAND_SZ, while they seem similar, we don’t have
> environment variables to expand in the value. If VERSION can be assigned as
> a string, why do we need to differentiate between STRING and FORMATTED?
> Either way, it seems that reg_none (no helper methods in regutil, so I
> missed this option) results in a hex(0): and reg_expand_sz results in a
> *From:* wix-devs *On Behalf Of *Sean Hall via wix-devs
> *Sent:* Thursday, April 29, 2021 11:04 PM
> *To:* WiX Toolset Developer Mailing List
> *Cc:* Sean Hall
> *Subject:* Re: [wix-devs] WIXBUG3704 - Allow access to persisted
> variables from related bundles
> We discussed this issue in
> (starts at 39:03). Most of that discussion was settling the
> hidden+persisted issue (compiler error - done) and the encryption issue
> (don't do it, pull the existing variable encryption - done). We agreed that
> the registry would be a good place to persist the variables but kicked the
> issue back to wix-devs to design how to store the types of the variables.
> That never happened, so here we are. Jacob has a draft PR at
> The current variant types are NONE, NUMERIC, STRING, FORMATTED, and
> VERSION. I think we can map these to the registry types REG_NONE,
> REG_QWORD, REG_SZ, REG_EXPAND_SZ, and REG_SZ, respectively. You might
> notice that REG_SZ is used for both STRING and VERSION. The only difference
> between these types is their comparison logic in conditions. When we
> designed FORMATTED, we decided to keep the v3 API surface where the BA was
> not able to ask what the current type of a variable is. So I think there's
> no problem here. This would mean that all types are stored transparently
> and easily consumable with minimal code. It also leaves REG_BINARY reserved
> in case something changes in the future, like adding new variable types.
> This does have implications on the APIs Jacob is adding to allow looking up
> arbitrary variables for arbitrary bundles. There is currently a method in
> those APIs that returns the type of the variable. It is currently returning
> a DWORD but I think that it should be returning an enum. This brings up a
> question I had about how to share an enum between the Burn headers and the
> dutil headers, which don't have any relationship today (I don't remember
> the context of that earlier discussion). I think we can sidestep that issue
> again by either removing the ability to query the type, or simply return
> the registry type. I think we should probably leave it in the dutil API but
> remove it from the engine API. Either way, I think the engine API needs to
> do the same coercion that it does for the normal variable get methods.
More information about the wix-devs