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

[Hoover, Jacob]

Editing a variable assigned to a check box in the options dialog uses the numeric setter.

This causes a difference in behavior between ui driven and command line driven.

Sadly, the engine internally abuses some numeric variables and sets them to NULL strings to uninitialize them.



> On Sep 25, 2019, at 3:14 PM, Hoover, Jacob via wix-devs <wix-devs at lists.wixtoolset.org> wrote:
> 
> Well, locally did a slight tweak (in variant.cpp) to be:
>    BURN_VARIANT_TYPE type = pVariant->Type != BURN_VARIANT_TYPE_NONE ? pVariant->Type : pValue->Type;
> 
>    switch (type)
> 
> And that seems to do good things.
> 
> Burn logs show setting a number to a non-numeric string results in Error 0x80020005: Failed to copy variant. Which is what I would expect.
> 
> 
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Bob Arnson via wix-devs
> Sent: Wednesday, September 25, 2019 2:56 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Bob Arnson <bob at firegiant.com>
> Subject: Re: [wix-devs] WixSdtBA: Variable types and command line arguments.
> 
> Users should be punished for their bad choices. 😊 Version variables too? What happens if there's an attempt to set a numeric variable with a nonnumeric value?
> 
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Hoover, Jacob via wix-devs
> Sent: Wednesday, 25 September, 2019 15:28
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: [wix-devs] WixSdtBA: Variable types and command line arguments.
> 
> 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
> 
> Thanks,
> Jacob
> 
> ____________________________________________________________________
> 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/
> NOTE: This email was received from an external source. Please use caution when opening links or attachments in the message.