Today's meeting is the first in 2022 and the first being live-streamed on YouTube. Those two (mildly) interesting facts did not substantially change our long-proven formula: Triage issues, talk about stuff, make bad jokes.

Issue triage

  • PDBs and source should be published on a source server, Burn (WixToolset.Burn.xxxx.nupkg) does not have a .snupkg, and Build v3-style to include native PDBs and matching sources for debugging form a trio of related issues with one goal: Provide the PDB symbol files for the native code in WiX, so users can debug problems in bundles or the WiX custom actions without needing to rebuild the entire WiX Toolset locally. In WiX v3, we accomplished this by shipping a .zip file that contained all the PDBs, including both native and managed code, and the matching source code. In WiX v4, we'd hoped to take advantage of slightly more advanced technology to provide a better experience. However, sometimes good old-fashioned technology works just fine, especially when the newer technology doesn't work well. Rob's comments in the first issue explain the issues. I reopened the last issue to track recreating the old-school .zip file. Sean volunteered to investigate what it would take to implement one of the more modern choices, though not necessarily in time for WiX v4.0.

  • Suppress (some) error logging, from @barnson, came about as I was examining a debug-level bundle log. WiX v4 adds logging from the DUtil library functions to the bundle log when logging at debug level. I wasn't quite mentally prepared for how much extra logging that would entail. And much of that logging is of the form "Error...Failed to do something," which is absolutely true (that registry key doesn't exist), a bit scary, and totally benign. I was a bit concerned about the tone of this benign logging so wanted to discuss it with more people than just my rubber ducks. We're not making any changes in WiX v4.0, but I volunteered to give it some additional thought for the future.

  • Detect when Restore is required for a .wixproj to build, from @robmen, came from Rob's live-coding stream, where he discovered the unpleasant experience of using an SDK-style .wixproj with package references when you don't first run a NuGet package restore on the project. So Rob gave himself extra work to make that experience better.