As promised, today we did our normal triage and we risked taunting the Demo Gods by having Rob run through the Windows Sandbox work I've done to run the WiX integration tests in a quick and easy virtual machine provided by Windows. Did the Demo Gods retaliate?

Issue triage

  • Light.exe failing to build from TeamCity when using Microsoft Merge Modules, from @jpwkeeper, reported what ended up being a failure due to the bane of all build systems everywhere: real-time antivirus locking files out of a sense of cruelty. (Prove me wrong!) WiX v4's consistent use of intermediate and output folders provides one way around this problem: Excluding those folders from real-time scanning. Unfortunately, that solution is often unacceptable to IT administrators, so Rob volunteered to investigate a retry mechanism for this code path in WiX v4.

  • RemotePayload prefers local files, even with hash mismatch, from @papeh, reports that Burn will glom on to an existing file, even if it's not the right match for a payload in a bundle. This is a bigger problem when you have files with common names across the decades, like vc_redist.exe. Sean volunteered to look into beefing up the engine to provide the BA with more data to make better decisions in this scenario.

  • Add standard Variable name validation to util:Searches and SetVariable, from @rseanhall, looks to prevent built-in Burn variables from getting overwritten. The built-in Variable element already does that and Sean is pointing out that the searches in WixUtilExtension and the new-to-v4 SetVariable element should get the same treatment. Rob enthusiastically volunteered to do so.

  • Add ability to specify that a custom action reference depends on architecture, from @rseanhall, came about from a bug in WixUIExtension that Sean investigated and who probably didn't originally cause the bug and let's not bother digging into whoever it was who did, OK?! Anyway, that bug exposed a complexity in the architecture-specific custom actions we introduced in WiX v4. Today, extensions use the architecture specified in the build to reference the appropriate architecture-specific custom actions. However, WixUIExtension is a bit special in that some custom action references happen from the dialog sets themselves and that WiX authoring is in a library and has no idea what the target architecture of the package is. Sean suggests custom action references could be tagged as being architecture-specific, to tell WiX to make everything line up at some point during the build. This wasn't in scope for WiX v4 anyway, but Rob suggested that this issue fits into some thinking we've been doing about how to deal with multi-targeting in general, across architectures, languages, and probably more. So I'll document this issue for WiX v4 and we have our first big problem to solve for WiX v5.

Running WiX integration tests in Windows Sandbox

As promised, today we showed off how you can run the WiX integration tests in Windows Sandbox and everything went off without a single hiccup. If you don't believe me, go ahead and watch the meeting recording above. If you do believe me, definitely don't watch the recording.