WiX Online Meeting #225 Highlights

Issue triage

• Bring back option to verify payload by Authenticode signature, from @rseanhall, was reopened after Rob tried to implement his portion of the work in his latest Let’s Code a Full 90 coding stream. The process of resuscitating Authenticode support, like a long shower, prompted the question of how it should be resuscitated. The primary use case for Authenticode support is for redistributable packages like the .NET Framework that can change after the bundle is built: Burn generally relies on hashes but if the downloaded file changed, the hash is invalid. Using Authenticode as the validation mechanism is weaker but ensures you still get your package. After our discussion, we ended up with Rob wanting to dig a bit deeper to see if .msu packages should get the same support. More discussion next time.

• WixBundleExecutePackageCacheFolder is not accessible in the BA process for per-machine packages, from @rseanhall, started as a question on the wix-users mailing list. After a bit of discussion, we agreed that a magic variable isn’t the right way to inform a bootstrapper application.

• Broken link on https://wixtoolset.org/development/assignment-agreement/, from @robmen, reports a bad URL in the WiX Toolset development documentation. Rob volunteered to make the URL better.

• Add ability to skip burn integration test during runtime, from @rseanhall, is looking for the ability to skip integration tests dynamically — such as when a build machine doesn’t have enough drive space for a test that takes up lots of bytes. It’s not straightforward at the moment, but we have workarounds we can use until such time as someone invests blood, sweat, and/or tears in this kind of infrastructure work.

• Add ability to specify Heat architecture from .wixproj, from @rseanhall, asks for a way to run a particular architectural flavor of Heat from a .wixproj. Sean notes that this was only recently supported in the .NET Core flavor of MSBuild. This issue is open for interested parties.

• RebootRequired volatile key doesn’t always go away, from @barnson, came about from an investigation into a Burn registration problem. Burn uses a volatile registry key to mark when a bundle requires the machine to reboot (to replace in-use files, for example). Volatile registry keys are perfect for this task: They magically go away after a reboot. Well, it turns out that simple statement used to be true but it became a more complicated statement in recent versions of Windows, which by default use a “fast startup” mode on shutdown that, it turns out, doesn’t clear out volatile registry keys. Given other weaknesses in this pending-reboot detection in Burn, we decided to remove it. I volunteered to do so, because deleting code is a rare pleasure.

• RegUtil doesn’t support creating or opening 32-bit registry keys, from @barnson, is the second issue of what I’m calling the Burn Registration Trilogy (Phase I in the WiX Cinematic Universe). The registry functions in the DUtil native library only partially support the 32-bit registry hive from 64-bit code. I volunteered to make it do so.

• BUtil needs to handle 64-bit registry for 64-bit Burn engines, from @barnson, is an understatement of a bug: In WiX v3, Burn was always 32-bit and wrote bundle registration to the 32-bit registry hive. In WiX v4, Burn is available for one 32-bit platform (x86) and two 64-bit platforms (x64, ARM64). Given issue #6669, a 64-bit Burn engine will write bundle registration to the 64-bit registry hive and won’t look in the 32-bit registry hive when detecting related bundles. That means a 64-bit bundle couldn’t upgrade a 32-bit bundle. That’s an important bug to fix, so I volunteered to support both registry hives.

• Extension for VS2022, from @pvkekem, is open as a subtle reminder that when we are ready to release the Votive extension for Visual Studio 2022, we need to add it to the WiX web site.

• Dark extracting COM+ applications with DARK1059 warning, from @bj185066, reports an unexpected error when decompiling an MSI package that includes references to the WiX COM+ extension. COM+ isn’t exactly a bleeding-edge technology, so this isn’t a high priority, but we took the bug into WiX v3.x for investigation.

• CanPatchSwidTag Burn integration test failing, from @rseanhall, is another issue to subtly remind Rob of something. In this case, it’s a failing test. Rob volunteered to make the test not fail.

• Dutch translation for UtilExtension for Wix v3 and v4, from @HarmvandenBrand, pairs a bug report with the pull requests needed to fix it. Yay, open source! Rob already took the localization fix in WiX v4 and took this issue to take the fix in WiX v3 before the next v3.14 build.

• WiX4 convert shows error messages which are actually informational, from @MarkStega, suggests that when the wix convert and wix format commands are fixing the problems they encounter, they shouldn’t be loudly proclaiming that there are errors. We agreed, and Mark agreed to implement the change. Again, yay, open source!

• Corrupt wixpdb when using WixUI_Minimal, from @rseanhall, reports a problem in the internal storage of Windows Installer data. Rob volunteered to investigate and fix.

• Command-line processing does not prevent execution on failure, from @robmen, is another issue Rob encountered during his coding livestream. (Apparently, coding live reveals even more problems than coding where nobody can watch.) Rob took this issue.

Coming to YouTube in 2022

With a few weeks of livestreaming on YouTube, Rob has decided to move the WiX Online Meetings there as well, starting with our first meeting in 2022. (That’s currently scheduled for 13-Jan-2022. Our next meeting scheduled for 30-Dec-2021 will still be on Twitch.) Keep an eye out for the YouTube URL in e-mail, GitHub discussion, tweet, or wherever else you get your WiX Online Meeting URL.