[wix-devs] WixSdtBA: Variable types and command line arguments.

Hoover, Jacob Jacob.Hoover at greenheck.com
Wed Sep 25 12:27:39 PDT 2019

Thinking this might be a bug/undocumented feature in WixStdBA or the engine.

<Variable Name="NUMERIC_VARIABLE" Value="1" Type="numeric" Persisted="yes" bal:Overridable="yes"  />

When one authors a variable w/ a type of numeric, sets overridable to true, and then passes a value on the command line, the internal type of the variable is getting set to string.  I believe the cause of this is ProcessCommandLine in WixStandardBootstrapperApplication.cpp, which is always using SetVariableString.  Ref: https://github.com/wixtoolset/wix3/blob/develop/src/ext/BalExtension/wixstdba/WixStandardBootstrapperApplication.cpp#L1242

While externally if we read this back as a number it is properly converted, internally it is then stored in the state data as a string even though the variable is defined as numeric.

Even more so, there is no type safety on the parsing because one can run Bundle.exe NUMERIC_VARIABLE=foo and it will happily change NUMERIC_VARIABLE to a string with a value of foo.  Then bundle logic breaks down when we attempt to get the variable as a number.

I would have expected Bundle.exe NUMERIC_VARIABLE=2 to change the value of NUMERIC_VARIABLE to 2 but leave its internal type as number.

My question is, should this be fixed to look at the variable's type before allowing the assignment (and converting it if possible)?  One could put this in WixStdBA or the Engine.

To me it seems that BVariantSetValue should be looking at pVariant->type instead of the new values type. Ref: https://github.com/wixtoolset/wix3/blob/develop/src/burn/engine/variant.cpp#L259


More information about the wix-devs mailing list