[wix-devs] Burn Variable breaking changes

Sun Jun 28 15:00:21 PDT 2020

I've done paths in BAs before and I don't know what you're talking about. FWIW.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Sunday, 28 June, 2020 17:30
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Burn Variable breaking changes

If you have a BA that's asking for a path, then you need behavior 1.
Otherwise, your bundle is not going to work correctly when the user picks a path with Variable special characters.

On Mon, Jun 29, 2020 at 6:39 AM Bob Arnson <bob at firegiant.com> wrote:

> FWIW, I've done more than a few BAs and never needed behaviors 1 to 3.
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of 
> Sean Hall via wix-devs
> Sent: Sunday, 28 June, 2020 00:53
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Burn Variable breaking changes
>
> There's a few scenarios for 4863.
>
> 1. Path variable. This one's straightforward, the editbox should be 
> populated with the literal value of the target variable. When saving, 
> the variable needs to have the contents of the editbox as a literal value.
>
> 2. Random string - user can't use Variables. The editbox should be 
> populated with the formatted value of the target variable. When 
> saving, the variable needs to have the escaped contents of the editbox 
> as the value ("abc[def]" needs to be saved as "abc[\[]def[\]]").
>
> 3. Random string - user can use Variables. The editbox should be 
> populated with... I don't know. Should it be the formatted or 
> unformatted value of the target variable? When saving, the variable 
> needs to have the unescaped contents of the editbox as the value.
>
> 4. Current v3 behavior. The editbox is populated with the unformatted 
> value of the target variable. The contents of the editbox are saved 
> unescaped.
>
> Even if we don't want to support some of these, I don't know how we 
> get around thmutil needing to know whether to alter the value before saving it.
> In that case, I would rather not have Variable/@Literal and instead 
> add a new variant type of BURN_VARIANT_TYPE_LITERAL_STRING. I feel 
> like it's more correct in saying that a string value is literal, 
> instead of declaring a Variable to be literal.
>
> On Sat, Jun 27, 2020 at 4:22 AM Bob Arnson <bob at firegiant.com> wrote:
>
> > I can't speak to managed BAs but in general, it seems like the BA 
> > would know about the variables it's querying or, if not, wouldn't 
> > care about the underlying type.
> >
> > -----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 19:18
> > To: WiX Toolset Developer Mailing List 
> > <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: Re: [wix-devs] Burn Variable breaking changes
> >
> > 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/
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant 
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/