[wix-devs] Burn Variable breaking changes

[Sean Hall]

Does Variable/@Literal just work? I'd have to think about the implications.
There'd be a bit on the Variable saying it's Literal, and there's also the
existing bit on the Variant saying the value's Literal. I'm not sure if
there needs to be support for asking whether the variable is a literal
string. Which is why I brought 5319 into this discussion. If we don't need
or want to add the ability for the BA to query the current type of a
variable, then I'll probably get rid of the separate collections.

On Fri, Jun 26, 2020 at 2:16 AM Bob Arnson <bob at firegiant.com> wrote:

> On 4863, I'm a little leery of trying to make thmutil too smart; if the
> bundle authoring can express the intent (Variable/@Literal="yes"?), then
> I'd say that's probably the better option.
>
> On 5319, I don't know enough about managed BAs to say much, but I've
> always found it weird that the different variable types are exposed in
> different collections, even if it makes sense when using them.
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Thursday, 25 June, 2020 07:47
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: [wix-devs] Burn Variable breaking changes
>
> I'd like to design the following issues so I know which ones require a
> breaking change:
>
> https://github.com/wixtoolset/issues/issues/4763
> https://github.com/wixtoolset/issues/issues/4863
> https://github.com/wixtoolset/issues/issues/5319
>
> 4763 added the ability for Burn to set a variable as a literal string. I
> think it's pretty straightforward to expose VariableSetLiteralString to the
> BA. Doesn't seem to be a breaking change.
>
> 4863 is about wixstdba (through thmutil) allowing an editbox to be either
> a literal string or a formatted string. If it's a literal string, then the
> value should not be expanded when populating the editbox. If it's a
> formatted string, then the value should be expanded when populating the
> editbox. Should thmutil ask for a SetLiteralStringVariable callback and the
> editbox is configured as literal/formatted in the theme? Or can a variable
> be authored as a literal string (so thmutil and wixstdba won't be aware
> that they're setting a literal string, the Burn engine will just handle
> it)? Making thmutil format the variable when populating the editbox is a
> breaking change, but adding the literal support doesn't seem to be breaking.
>
> 5319 is about the managed BootstrapperEngine implementation where it
> exposes StringVariables, NumericVariables, and VersionVariables. The
> complaint is that calling NumericVariables.Contains("StringVariableA")
> returns true even though the variable is actually a string and not a
> number. Do we remove the Contains method from all 3 and provide a single
> Contains method so it doesn't imply that the variable is of the requested
> type? Or does Burn provide a way to expose what the current type of a
> variable is? Either way sounds like a breaking change.
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>