Remove WiX prebuilt from Workloads tooling by removing the PackageReference during source-build

• This issue is blocking
• This issue is causing unreasonable pain

---

• For https://github.com/dotnet/source-build/issues/2411

Microsoft.DotNet.Build.Tasks.Workloads.csproj pulls in a WiX NuGet package, which is not currently built from source:

https://github.com/dotnet/arcade/blob/020ac68b5848016459652ebf4ed965b9800fe426/src/Microsoft.DotNet.Build.Tasks.Workloads/src/Microsoft.DotNet.Build.Tasks.Workloads.csproj#L22

https://github.com/dotnet/arcade/blob/020ac68b5848016459652ebf4ed965b9800fe426/src/Microsoft.DotNet.Build.Tasks.Workloads/src/Microsoft.DotNet.Build.Tasks.Workloads.csproj#L29-L33

https://www.nuget.org/packages/WiX/3.11.2

I’d like to remove this package and those references when Arcade builds under source-build. I see a few ways to do it:

• Exclude all .cs files from the build that use the reference.
  • Could either move some .cs files into a “WiX” subdir and exclude it from the build, or rename some files to .wix.cs and exclude it with a pattern.
• Use compiler directives and the preprocessor to tweak the files at a deeper level.
• Create a new Arcade project that contains WiX functionality and link it in as a separate package. This is easier to maintain (your IDE helps you stay within the guard rails rather than only seeing issues during source-build) but probably harder to set up.

@joeloff, @pjcollins, do you think this approach of making the WiX NuGet reference conditional for source-build sounds reasonable? (Are there more people who should weigh in? I just peeked at Git history. 😄)

I can try it out and submit a PR for you take a look if you don’t have the bandwidth to spare. (I’m temporarily helping with the 6.0 source-build prebuilt removal effort overall.)

---

@dseefeld is also looking at whether the WiX package can decompiled into https://github.com/dotnet/source-build-reference-packages (SBRP). This means the DLL can’t actually be executed anymore, but it seems unlikely that the WiX DLLs would actually be used for Linux/macOS builds from source, so that is probably fine. But, potential problems:

• The MS-RL license could be an issue. I believe it’s a brand-new license as far as .NET source-build is concerned.
• The unusual way the WiX package’s DLLs are laid out (in tools/) doesn’t work well with the existing SBRP tooling.
• Putting the WiX package in SBRP also increases maintenance burden when the package gets updated.

The potential issues with that approach are why I’m investigating if removal is possible.

[dagood]

I’ve submitted PR https://github.com/dotnet/arcade/pull/8016 with the .wix.cs approach, which seemed to work cleanly. I’m running a 6.0 tarball build with the change as a patch to make sure there aren’t any downstream errors.

[joeloff]

The finalizer is for Windows installer only. It’s a native C++ EXE we run on Windows when the SDK is removed to clean up any workloads that were acquired through the CLI.