We're at that point in Northern Hemisphere summer where the weather is actively taunting us. For me here in the USA Midwest, late July is usually the swampiest part of summer. But this week, it's comfortable during the day and actually chilly at night. It won't last, of course. Rob's dealing with the outdoors at body temperature, which is the weather being so mean to all those Washingtonians who don't have air conditioning because it's hardly ever needed. Until it is. I wonder if I could buy a nice three-bedroom cave somewhere...
WiX Online Meeting 309 Highlights
Wednesday, July 22, 2026
Issue triage
-
WixStandardBootstrapperApplication window disappears behind Windows Explorer window, from @tzehetner, is an unfortunate bug that can happen when launching a bundle via that convenient double-click from Explorer. Sometimes when launching the bundle for elevation, Windows likes to give focus back to Explorer instead of the original window where it belongs. Rob was intrigued enough to volunteer to investigate it.
-
The InstallDir_SpecialDlg does not work / needs updating, from @neilc222, suggests that test code should be production ready. I’d argue that test code is just for testing except where the developer suggests otherwise. Unfortunately somebody suggested that, even going so far as to put a link to it in the documentation. How rude. So I volunteered to fix it.
-
Burn containers build should be parallelized like package .cabs, from @barnson, came from my explorations into the internals of Burn compression. Unlike packages, where multiple .cabs are built in parallel, WiX doesn’t build multiple containers in parallel even though they’re also .cabs. I’ll suggest they should though I didn’t volunteer to change this, as I’d rather work on getting Burn containers compressed with LZMA instead of as .cabs.
-
WixStdBA v7 does not show UAC shield anymore for single-scope per-machine bundles, from @dallmair, is related to but unfortunately distinct from a bug we triaged last month. Though I maintain my innocence, the root cause might be somehow related to the changes I made in WiX v7 for configurable-scope bundles. That being the case, I volunteered to fix this issue too.
-
Consider building ARM64 custom actions as ARM64X, from @barnson, is the result of my exploration into a bug reported by a FireGiant customer. When an Arm64 upgrades an x64 package—common for ISVs that “settled” for x64-on-Arm64 until they added full Arm64 support—Windows Installer mistakenly tries to run Arm64 custom actions in the custom action sandbox processes that the upgraded x64 process created. A workaround for this bug is to create Arm64 custom actions as Arm64X binaries, which contain both Arm64 code (i.e., incompatible with x64) and Arm64EC code, which happens to be compatible with x64. Due to how Arm64X DLLs are generated, they’re compatible with Windows 10, which doesn’t support Arm64EC or Arm64X. So this change wouldn’t introduce any compatibility problems for any devices still running Windows 10 (if any).