I think the 5.0.0-rc.1 release broke our build

[thallgren]

Hi, our CI build started failing a couple of hours ago. We do this:

dotnet tool install --global wix --version 4.0.4
wix build -o telepresence.msi telepresence.wxs
wix extension add -g WixToolset.Bal.wixext
wix build -ext WixToolset.Bal.wixext -o ".${BINDIR}/telepresence-setup.exe" bundle.wxs

The last command results in:

wix.exe : error WIX0144: The extension 'WixToolset.Bal.wixext' could not be found. Checked paths: WixToolset.Bal.wixext, C:\Users\thhal\.wix\extensions\WixToolset.Bal.wixext\5.0.0-rc.1\wixext4\WixToolset.Bal.wixext.dll

Note the mention of 5.0.0-rc.1 here. We installed 4.0.4.

[thallgren]

I also tried to explicitly set the version, e.g.:

wix extension add -g WixToolset.Bal.wixext/4.0.4

but that doesn't help. Still the same error mentioning 5.0.0-rc.1

[barnson]

I'd expect this to work but I'd also expect a lack of a version to indicate "latest release." Please open a bug so we can triage this.

[thallgren]

Adding a version to the actual wix build -ext works though:

wix build -ext WixToolset.Bal.wixext/4.0.4 -o ".${BINDIR}/telepresence-setup.exe" bundle.wxs

[robmen]

WixToolset.UI.wixext 5.0.0-rc.1 (damaged) <-- Seems to me that this is not intended to happen

If you are using wix.exe v4 then this is exactly what I'd expect. The WixToolset.UI.wixext v5 does not support WiX v4 and so it is reported (damaged) by WiX v4.

As noted above, the error messages could definitely be more helpful.

[gvdvenis]

If you are using wix.exe v4 then this is exactly what I'd expect.

Not sure what you mean with this or if I maybe misunderstood what your saying here. I guess it's expected behavior if you compare how it works now. However, from a users perspective this is different.

My CI does a dotnet tool install wix --global --version 4.0.4 . If I then invoke the wix build -ext WixToolset.UI.wixext command I would expect it to be using the same version of the extensions, which I explicitly added to the install command.

Not sure if I'm correct here, but it seems that the dotnet tool install command (potentially) installs different binaries each time it is run, even if I explicitly provided the desired version. It can therefore not be used reliably in CI/CD on its own now, because it obviously breaks my builds.

Therefore I now install the extensions before using the wix build command like this:

wix extension add "WixToolset.Util.wixext/4.0.4"
wix extension add "WixToolset.Bal.wixext/4.0.4"
wix extension add "WixToolset.Netfx.wixext/4.0.4"
wix extension add "WixToolset.Ui.wixext/4.0.4"

Which works, but IMO it should not be necessary in the first place.

[jcasale]

@gvdvenis This is already being addressed in #8033

[barnson]

I would expect it to be using the same version of the extensions,

WiX doesn't impose such a requirement. Extensions can have any version they want. If you want "immutability," specify the versions of every component you care about.

[robmen]

I guess it's expected behavior if you compare how it works now.

Yeah, WiX is an open-source project, so I looked at the source code. It was behaving correctly (aka: as written).

but it seems that the dotnet tool install command (potentially) installs different binaries each time it is run, even if I explicitly provided the desired version

If you do NOT provide a complete version then I agree. If you DO provide a complete version then it should always install the same tool (as long as you don't modify your NuGet sources). In the end, dotnet tool install behaves quite similarly to wix extension add.

I would expect it to be using the same version of the extensions

It would be nice if a WiX extension could better advertise which WiX versions it supports, much like how "normal" NuGet packages can declare their supported TFMs. There are many parallels between WiX-supported versions and TFMs. For example, a single WiX extension can support multiple WiX versions, and (as Bob points out) WiX extension versions have nothing to do with the underlying wix.exe/WixToolset.Sdk version.

Basically, these are all opportunities for the existing code to be enhanced.

[chrpai]

I've been doing a lot of Blazor/MudBlazor work lately and what they do that I like is they don't specify a version on the Sdk reference and then say Major.* for all of the package references. If this could automatically keep me up to date on the latest 4.x and then hop me over to 5 when it's out of RC that would be ideal to me.

The Chris from 10 years ago can't believe that the Chris today just wrote that. :)

[robmen]

That's because dotnet ships their SDK. We don't have that privilege.

[chrpai]

Maybe the dotnet tool wix.exe could have an evergreen command that updates all of the versions in a solution. Then people get used to adding that as a prebuild step. I'll probably write my own soon because I have so many installers that I maintain that keeping up with the Jones is just not happening.