[wix-devs] Burn Variable breaking changes

Sun Jun 28 15:20:29 PDT 2020

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