WixSharp generates wix.tools.csproj with floating versions (*) causing unintended upgrade to WiX v7 and build failures (WIX7015)

[pIIrash]

Hi,

We are encountering an issue with WixSharp (using WixSharp_wix4 2.7.3) where builds suddenly started failing both locally and in CI (Azure DevOps) with the following error:

WIX7015: You must accept the Open Source Maintenance Fee (OSMF) EULA to use WiX Toolset v7.

After investigation, it appears that WixSharp generates a helper project at:

%USERPROFILE%\.wix\.wixsharp\wix.tools\wix.tools.csproj

This generated project contains PackageReference entries with floating versions:

  <PackageReference Include="WixToolset.Dtf.CustomAction" Version="*" />
  <PackageReference Include="WixToolset.Dtf.WindowsInstaller" Version="*" />
  <PackageReference Include="WixToolset.Heat" Version="*" />

Because of the floating versions ("*"), NuGet restore resolves to the latest available WiX Toolset packages, which currently means WiX v7. This introduces:

• unexpected upgrade from WiX v4/v6 to v7
• breaking changes (e.g. Heat removal)
• mandatory OSMF EULA acceptance (WIX7015)
• non-deterministic builds depending on restore time

This behavior is especially problematic in CI environments where there is no prior cache and restore always resolves to the latest versions.

Observed behavior:

• Builds previously worked (likely due to cached older versions)
• After clearing cache or on clean agents, builds fail with WIX7015
• Local environment started failing as well after deleting the .wix cache

Questions:

1. Is there a supported way to control or pin the WiX Toolset version used by WixSharp-generated wix.tools.csproj?
2. Is there a recommended approach to avoid floating PackageReference versions in the generated project?
3. Can WixSharp expose configuration (e.g. via MSBuild properties or environment variables) to enforce a specific WiX Toolset version?
4. Is this behavior expected with WixSharp_wix4, or should it be considered a bug?

Current workaround:

• manually patching wix.tools.csproj to replace Version="*" with a fixed version (e.g. 6.x)
• or injecting AcceptEula=wix7 via global MSBuild properties

However, these approaches are fragile since the file is regenerated.

Any guidance on a proper and supported solution would be greatly appreciated.

[oleg-shilo]

Yes, compatibility is the problem since WiX team, not so long ago, started pushing new breaking changes with new releases.

Place this code (with your desired version) at the top of your build script, and it will trigger installing local wix tools (to the specified folder):

wixsharp/Source/src/WixSharp.Samples/Wix# Samples/Driver/setup.cs

Line 17 in 7ffa9d0

WixTools.SetWixVersion(Environment.CurrentDirectory, "4.0.6");

This should help with the selection of the compilers (e.g. wix.exe).

However, it will not help with the selection of the assistance tools that are not distributed as ".NET Tool" but rather as ".NET Package". WixSharp is using "wix.tools.csproj" to pull these packages.

I will update teh API to allow handling this problem:

• use specific version of the .NET package to be restored. By default, it will be the same as WixTools.GlobalWixVersion.
• allow specifying EULA acceptance according to the WiX team guidance.

[oleg-shilo]

It will not be long. A few days or so.

But until you wait, you can use this workaround:

1. in the CI environment have a copy of %USERPROFILE%.wix.wixsharp\wix.tools\wix.tools.csproj.
   Ensure it has correct versions of teh ref packages
2. install packages with dotnet restore
3. Then proceed with WixSharp build as normal. It will find the packages you just restored

UPDATE: You can perform steps 1-2 automatically by simply adding the packages to your WixSharp project. It doesn't matter which C# project triggers the package download. So it can be your very project that builds the msi.

[pIIrash]

Thank you for your assistance.

I will try your suggestions until.

[oleg-shilo]

I have prepared the prerelease so you can test it before I republish it as a normal release.
Thus, you can update your packages to v4.2.13.0-pre from www.nuget.org.

After the update, you do not need to change your code. The nuget packages will be downloaded for the version that is the same as your WiX Toolset. Though if you have WiX 7 installed on your system, you will need to downgrade it locally for your project to v6 (or lower) with WixTools.SetWixVersion(Environment.CurrentDirectory, "6.0.2");

---

A quick summary of changes:

• by default, the WiX version-sensitive packages will use global WiX version to match, not the maximum version available.
  Thus, the following code:

  WixTools.SetWixVersion(Environment.CurrentDirectory, "6.0.2");
  Console.WriteLine(WixTools.WixToolsetMbaCore);
  Console.WriteLine(WixTools.Heat);
  Console.WriteLine(WixTools.MakeSfxCA);
  Console.WriteLine(WixTools.SfxCAFor(is64: true));
  Console.WriteLine(WixTools.SfxCAFor(is64: false));

  will print:

  Wix version: 6.0.2
  C:\Users\user\.nuget\packages\wixtoolset.mba.core\4.0.6\lib\netstandard2.0\WixToolset.Mba.Core.dll
  C:\Users\user\.nuget\packages\wixtoolset.heat\6.0.2\tools\net472\x64\heat.exe
  C:\Users\user\.nuget\packages\wixtoolset.dtf.customaction\6.0.2\tools\WixToolset.Dtf.MakeSfxCA.exe
  C:\Users\user\.nuget\packages\wixtoolset.dtf.customaction\6.0.2\tools\x64\SfxCA.dll
  C:\Users\user\.nuget\packages\wixtoolset.dtf.customaction\6.0.2\tools\x86\SfxCA.dll

• If the packages are not available, WixSharp will try to download them.
• When downloading the packages, WixSharp uses WixTools.WixDtfPackages, which lists DTF tools packages and their versions. The user can override this property.
• User can always force downloading the fresh packages with WixTools.RestoreDtfPackages().

[pIIrash]

NU1102: Unable to find package WixSharp_wix4 with version
error: Package 'WixSharp_wix4' is incompatible with 'all' frameworks in project

<PackageReference Include="WixSharp_wix4" Version="2.12.3" />
<PackageReference Include="WixSharp_wix4.bin" Version="2.12.3" />
<PackageReference Include="WixSharp-wix4.WPF" Version="2.12.3" />

<TargetFramework>net48</TargetFramework>

[oleg-shilo]

You need to enable importing pre-release packages:

Though I suggest you wait now, as I have finalised the API and am preparing the proper release right now. Thus, you will not need to deal with the pre-release.

[oleg-shilo]

Done, a normal release v2.13.0 is available now: https://www.nuget.org/packages/WixSharp_wix4

[pIIrash]

Thanks for the quick turnaround on this — really appreciate it. 🍻
I tested the fix and can confirm it resolves the issue on our side. Everything builds successfully now.

Btw this way my quick workaround before the fix:

          - powershell: |
              $dir = "$env:USERPROFILE\.wix\.wixsharp\wix.tools"
              New-Item -ItemType Directory -Force -Path $dir | Out-Null
              @"
              <Project>
                <PropertyGroup>
                  <AcceptEula>wix7</AcceptEula>
                </PropertyGroup>
              </Project>
              "@ | Set-Content "$dir\Directory.Build.props"
            displayName: Prepare WixSharp props

[oleg-shilo]

Great, thank you.

[oleg-shilo]

I captured all aspects of dependencies management here: WiX Toolchain Integration (Wix3, Wix4, WiX6‐7)
To a large degree, it is a reflection of what we discussed here.

[Lindsay-Mathieson]

Done, a normal release v2.13.0 is available now: https://www.nuget.org/packages/WixSharp_wix4

Thanks you so much! was caught out by this generating a new release today, really saved my bacon.