WiX v5 - toolset replacements

[joeloff]

Hi

What happened with all the old tools, e.g. retina.exe? I noticed some tools like insignia still exist as part of wix burn. Is there supposed to be something like wix wixlib decompile like wix msi decompile is effectively dark.exe?

Same goes for Heat. Am I supposed to do dotnet run heat.dll as opposed to heat.exe?

Can you still invoke the logic of just the linking step, e.g. taking the wixobj files and just running light? Is that something that's supported in wix build? In v3, I could run light -out foo.msi a.wixobj b.wixobj. If tried that, but received an error: A WiX source file must use 'Wix' as the document element name. Some tools like pyro appear to be inferred based on the file extensions of the output, like .msp.

Is there a list of tools that were dropped or integrated into a new command/sub-command?

[wmanning]

Wix4 was a big release that changed a lot.

• Heat is available in nuget: https://wixtoolset.org/docs/tools/heat/
• dark as wix msi decompile: https://wixtoolset.org/docs/tools/wixexe/

Wix5 introduced:

• file harvesting which may replace heat for a lot of people: https://wixtoolset.org/docs/fivefour/#file-harvesting

[joeloff]

retina was used in wix3 to compile or decompile a wixlib, for example, if your wixlib contains both compiled .wxs sources and say a binary custom action, retina can be used to separate them or put the files back into a wixlib again. That's typically how extensions work in WiX. You build a compiler extension DLL. That DLL contains a wixlib as an embedded resource and the wixlib contains the setup authoring and additional binaries that could then be linked into an MSI or something else like a bundle.

[barnson]

Retina existed as a hack so DevDiv could ship the VS remote debugger on Windows RT back in 2012(!?), so we didn't bring it to WiX v4.

[joeloff]

Thanks Bob. I take it the wixlib format changed (I did try running against a v5 wixlib and ended up with error RETI0104 : Not a valid object file; detail: Data at the root level is invalid. Line 1, position 1.).

[barnson]

Very much.

[robmen]

A question and a tip.

1. Why are you trying to use retina?

2. As per WIP: Organized obsolescence of Heat in v4 #6838, heat.exe is being obsoleted (use Files element instead). If you really must use it from the command-line, see this part of the WIP:

   For use outside of MSBuild, heat.exe could be acquired via nuget.exe install and the executable should be available in the tools\<tfm> folder.

[joeloff]

Hi Rob

1. We need to sign all executables with additional certificates to comply with WDAC Code Integrity policies that block executables that don't meet certificate requirements. We have customers whose own internal policies stop them from expanding the allow lists for CI in certain environments. For MSIs, most of the standard custom actions come from the various extensions and are embedded in the wixlibs that in turn are embedded in the DLL resource streams. It's possible to export the Binary table and scan for PE headers and try to sign those files, but it's expensive to replicate across large projects where we have hundreds of pipelines (and risk missing some). Having a single copy of the toolset that meet the signing requirements is much simpler. Bootstrappers are also a bit complicated. While Insignia can detatch and reattach the engine, files like the standard BA (wixstba) also come from an extension. Signing once also provides stable hashes for the binaries that sometimes trigger false positives for end-point security software.

2. I had a build task that generated standard MSIs, including the source code, some of it from predefined fragment templates while other pieces are unique and harvested directly so my task calls out to Heat/Candle/Light. But I think I can adapt it to work in the new tool-based paradigm. I can just have my task generate a proper .wixproj along with all the other source files.

[robmen]

1. This sounds like something everyone needs. Seems like something we should solve in the WiX Toolset instead of specialized hacking of the binaries later. What is necessary to make that happen?

[joeloff]

The simplest solution is asking customers to include the .NET Foundation/DigiCert certificates in their CI policy, but some customers will push back and I completely understand that.

1. Someone could fork the repository, build and hook in their signing logic - the details of the signing step is going to vary for each build environment. It also means losing the WiX/.NET Foundation/DigiCert signature - personally I like retaining the signature because I know I'm starting from a known, trusted build. More importantly, the file versions line up with official WiX releases. Any scans that happen during a build to verify your toolset is secure will be confused when it sees different versions. You could tweak your fork to match the version of an official release and make sure your commits line up, but that borders on spoofing for me.

2. Unpack, sign, repack the toolset and push that to an internal feed in your organization and share it across product builds so there's one source of truth. This is what we did for v3. You end up losing some information, but you retain the file version information and the original signature if your certificate supports dual signing. Authenticode signatures can sometimes replace. For us the process went something like this:

   • Grab all the WiX*Extension DLLs and ildasm to pull out the embedded resources.
   • For any resource that has a .wixlib extension, run retina to decompile
   • Sign DLLs that came from the .wixlib along with other binaries, e.g. BootstrapperCore.dll or the DTF libraries since.
   • Call retina to link the .wixobj and binaries back into a .wixlib
   • Call cvtres to convert resource files to an object resource (this tool only exists in .NET Framework).
   • Call ilasm to embed the resource back into the extension DLL

This approach isn't ideal either.
- You lose signatures in the compiler/linker extension assemblies. Those aren't usually redistributed, so probably not too bad.
- Any organization that needs to deal with WDAC/CI need to implement this process to fit with their internal engineering system.

In the v5 world, I'd imagine we'd need something like wix lib extract and wix lib update as a command, but that is somewhat clouded from thinking in terms of how retina worked.

3. This is the way-outside-the-box solution. Generate a partial build of all redistributable binaries of WiX, like a zip or a nupkg (since we can sign nupkgs). For example, this would contain wixstdba.dll, SfxCA.dll, etc. All of these are signed with the WiX certificate. The archive of signed files would be part of an official release. Users could download these and simply apply their additional signatures. When you build/link an MSI or bundle, you can pass an additional option that point to a source of binaries that need to be swapped/injected.

A variation of this would be to use the intermediate signed outputs to complete a build inside a fork of the repo. I suspect option 3 would be costly on the WiX toolset, but wanted to just throw it out in case it sparks a better idea in someone.

[heaths]

Would a better solution - one with precedent via Insignia - be to hook the signing process when building packages?