Today's triage focused primarily on the rise of reports of problems installing Votive into the latest point release of Visual Studio 2022. My suggestion of going back to Notepad-based development was not broadly accepted. We're keeping an eye on the problem and hope to hear back from Visual Studio folks by the next meeting, so stay tuned.
WiX Online Meeting 237 Highlights
Thursday, June 9, 2022
Issue triage
-
Installation of VS 2022 Extension corrupts VS, from @beinhaerter, Wix toolset visual studio extension not getting installed with Visual studio community edition , from @Sandeep2000gupta, Unable to install Wix extension into Visual Studio Enterprise 2022 (17.2), from @Nico-1987, and Random failures installing Votive, from @JVimes, are issues we’ve received lately about problems installing Votive on Visual Studio 17.2. (That’s the released version, not the Preview version which had its own problems that the Visual Studio team fixed before release.) Unfortunately, especially for a bunch of setup nerds, we don’t have any control or even insight into how VSIX packages are installed. There’s an issue open on Visual Studio’s developer community site about this issue — if you’ve experienced this problem with Visual Studio 17.2, please up-vote that issue so Microsoft is aware of the impact. In the meantime, we’re tracking this issue in Votive has problems installing in Visual Studio 17.2.x, from @barnson.
-
The “Files in Use” dialog appears when a WiX installation does a Repair, from @MrGaryTaco, was a detailed report — lacking only that most sought-after debugging aid, the verbose log! — about an unexpected files-in-use message. As files-in-use detection is handled inside the Windows Installer engine and not WiX-the-build-tool, we moved this issue into a discussion.
-
Should KB attribute be removed from MsuPackage element and/or WixBundleMsuPackageSymbol, from @robmen, came from Rob’s livestream last week: As Windows removed the ability to silently uninstall MSU packages, we decided to remove Burn’s attempt to do so. The
KBattribute was used only to uninstall MSU packages, so now that Burn doesn’t do that, there’s no need for theKBattribute. Rob contemplated keeping it as a form of documentation. I might have replied that seemed a bit like digital hoarding, given that the KB number is usually part of the file name. Also, XML has comments. Rob decided that I was, as usual, correct, and agreed to remove the attribute and the matching property from the internal symbol. -
Can PackagePayloads be verified differently from “child” Payloads?, from @robmen, is another topic from Rob’s livestream this week: Should different payloads for a particular package support mixing verification methods (hash versus Authenticode signing)? We agreed that there’s a need to support an Authenticode-signed package with hash-verified payloads because some files can’t be signed (like text files). The other mix, a hash-signed package with Authenticode-signed payloads feels like an unlikely scenario, but we couldn’t come up with a good reason to do the extra work of disallowing it.