WiX Online Meeting #148 Highlights

Today was another triage-only meeting but this time we had a few bugs that prompted more discussion than usual, so we ended up with a nicely-timed 30-minute meeting.

Issue triage

Command line arguments swallowed by burn - affecting related bundle detection, from @OndrejVrsan, came back with additional detail and we concluded that Burn is working as designed. When users pass in a -h switch, Burn swallows that switch and tells the BA that the user chose the Help action.
DependencyDetectProviderKeyPackageId regressed to no longer return success after finding first provider key, from @MattHyman, was a bug that came in, was fixed by the reporter, and the pull request merged, all since the last meeting. Yay for open source!
WiX toolset does not install targets into Microsoft Build Tools 2017 folder, from @antrv, expected the WiX MSBuild targets files to be installed into the Visual Studio Build Tools SKU directory. As those of us who went through the painful breaking changes in Visual Studio 2017 and MSBuild v15 last year will recall, VS2017’s new support for multiple instances makes it painful to do things the way they used to be done. Rob volunteered to write about how .wixproj files need to be adapted if they were created before the new WiX v3.11 templates.
WixErrors.UnexpectedException does not display all parameters in the output windows, from @armsee, points out that the Visual Studio error list restricts error messages to their first line of text. For the UnexpectedException error message (sometimes referred to as the “oh expletive something went wrong” message), the most useful bit is the stack trace, which is always guaranteed to take multiple lines. So we deferred, suggesting instead to rely on verbose MSBuild logging, which will contain all the gory, delicious details.
burn /quiet option for MSP that uses DisplayInternalUI=yes still shows UI , from @GregDomjan, demonstrates a problem with the frequently-problematic DisplayInternalUI attribute. In this case, DisplayInternalUI doesn’t match the UI to the UI of the bundle as a whole, so we took the issue into WiX v4 to investigate. It also prompted a discussion after the meeting about a way to better describe the limitations of DisplayInternalUI. More soon.
Missing documentation in WiX v3 manual: Creating a bundle package (VSxx), from @sixnoteprod, suggests a way to improve bundle documentation. Improved documentation is always a good idea, so we kept the issue around.
Errors.resources files are somehow corrupt, from @eug48, seems to be pointing to binary .resources files having embedded line endings munged in Git. As they should be built anyway, we took this as a build process bug.