WiX Online Meeting 312 Highlights

WiX v7.0.1

October’s Patch Tuesday release saw an impressive number of CVEs fixed in .NET. One of those CVEs is present in an assembly that WiX includes from a transitive dependency. We are confident it doesn’t result in a vulnerability in WiX itself. Nevertheless, the “bad” assembly is present in the WixToolset.Sdk NuGet package and will probably make security scanners angsty. Therefore, we’re releasing WiX v7.0.1 to make a clean NuGet package available. Release goddesses willing, WiX v7.0.1 will be published on Monday, 26-October.

Issue triage

• wix msi transform does not include binary difference, from @schup2025, discusses a change in behavior in wix msi transform compared to WiX v3’s torch. WiX v4 adds the ability to create a transform without differences in embedded files, like a custom action DLL in the Binary table. That’s desirable behavior but it should be possible to include them. A new contributor opened a pull request to fix this issue that Rob is looking at.

• Clean up IPreprocessContext, from @barnson, comes from my discovery while using the WiX preprocessor in some custom tooling that the IPreprocessContext context used to control the preprocessor has some unused bits. The plan is to mark them obsolete so “someone” doesn’t spend time trying to figure out what they’re used for.

• “Cabinet 1 not provided” error for specific MSIs, from @ulrichb, appears to be a bug (or missing feature, to be technically correct) in DTF’s support for CAB decompression. WiX’s support for “smart cabbing” takes advantage of a CAB API feature to duplicate a CAB entry for duplicate files without duplicating the compressed data. That requires extra work that DTF doesn’t do. This issue is up for grabs for someone wanting to delve into the CAB APIs for fun.

• WixException(Message error, Exception exception) should include sourceLineNumbers. and WixException should include InnerException, both from that charming @barnson, are related requests after suffering from a less-than-useful error message. “PC Load Letter” indeed. In this case, WiX wrapped another exception in a WixException but by default, the new exception message is limited to the original exception’s message. An inner exception typically contains the underlying failure and hey, the source line number is always handy in a pinch. That information is available if your code can catch the WixException but if not, the extra data was just thrown away. I opened a pull request to optionally add the detail in the message.

• Consider Arm64 build and/or test, from @barnson, came to mind now that GitHub supports Arm64 build images: We could explicitly test Arm64 components on Arm64. Today, I test my Arm64 work by hand on “spare” Arm64 hardware but it’s sporadic at best. We should test on Arm64 more frequently. So I took this issue and will investigate what’s needed to wire it all up.