Welcome to the November 2024 WiX Online Meeting as we start accelerating down the hill toward the end of the year. In fact, our next meeting on 17-December will be the last of 2024! Join us then for a pre-solstice celebration of bugs and feature requests.
Issue triage
Heat is not harvesting native x64 COM DLLs properly, from @Nico-Ko, suggests that the support for harvesting 64-bit COM registration that Heat got in WiX v4 is less than perfect. Quelle surprise! Though Heat is deprecated and will one day be buried at sea in a solemn ceremony, for now it's still around and will be around for at least one more WiX release, so we would take a pull request to fix this issue.
Hide "Files In Use" dialog behaving as if ignore was chosen, from @charles-juicelabs, requests (and provides) support for suppressing the files-in-use dialog that's part of WixStdBA. We need to review the pull request but we agree that the request and approach are reasonable.
WixInternalUIBootstrapperApplication bundle fails silently on downgrade, from @BramWesselink-benchmark, laments that WixInternalUIBootstrapperApplication, which has no UI in favor of the UI of its MSI packages, has no UI. Specifically, it has no UI to show an error message that happens before handing control over to the MSI packages. But it could—Burn and WixStdBA show message boxes in similar "early error" conditions. We'd need to see a WIP to make sure any such change doesn't degrade the desired MSI-forward UI experience but otherwise, a message-box-like UI is acceptable for WixInternalUIBootstrapperApplication.
WIX0001 - Illegal character in path, from @MyKeySoftMK, reports a problem that turns out to be user error when using preprocessor variables hide too much context. But the resulting bad path resulted in an exception and we generally feel that exceptions are bad and should be reported less abruptly and more helpfully.
Cannot extract Burn engine from bundle, from @petm2022, now has a more accurate title: Uncompressed bundle doesn't need two-step signing. Burn bundles need special handling—typically—to handle correctly signing a compressed bundle. It needs one signature for the bundle with the BA attached and another for the whole bundle with the compressed packages attached. However, if you have an uncompressed bundle (i.e., one with no packages attached), the "whole bundle" is the "bundle with the BA attached," so the two-step signing isn't necessary. It's harmless, but the one-step process should be documented, if only for pedantic completeness (the best kind of completeness).
A dummy short file name generated in RemoveFile that might cause a wrong file to be deleted, from @nirbar, suggests that it might be a bad idea to generate short file names. Short file names—does anybody remember that back in the olden days, file names were limited to eight characters and extensions to three characters? In fact, it wasn't "characters," it was bytes, because Unicode didn't exist and we didn't even use all eight bits of the byte; we used seven bits of ASCII and we liked it! Where was I? Oh right, short file names were still (technically) required back when MSI was in development, so MSI requires a short file name be provided whenever a long file name is given. One of the very happy reasons to adopt WiX v3 back then was that WiX v3 automatically and safely generated stable short file names so they no longer had to manually authored. That short file name generation continues to this day and this issue suggests that it's not necessary and maybe even dangerous to do so in some places. Rob volunteered to investigate.