[wix-devs] Burn Variable breaking changes

Tue Jun 30 08:49:08 PDT 2020

> 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.

So, Variable/@Literal would initialize the type on the variant to "BURN_VARIANT_TYPE_LITERAL_STRING"? After that would there be a way to convert the variant to a formattable string? 

The Windows Installer has the same challenges with its UI. Perhaps we should consider how they addressed these issues.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Sunday, June 28, 2020 3:20 PM
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 the user picks C:\[Folder], then that's what's stored in the Variable.
Then when Burn passes that on to the package, it's going to format it. So it turns into C:\ or it turns into C:\formattedFolder. Just like explained in 4763.

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

> 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/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/