WiX Online Meeting #147 Highlights

On this fine spring day, we had a quick bout of triage as we get back on track to our normal fortnightly meeting schedule.

Issue triage

Command line arguments swallowed by burn - affecting related bundle detection, from @OndrejVrsan, reports a potential problem with Burn command-line parsing. We’re not 100 percent sure what the bug is, because by design, Burn removes command-line switches it handles (like the standard /quiet or /help switches), so we asked for logs to dig a bit deeper.
Wix bundle removes symbolic link to “Package Cache” when uninstalling and upgrading, from @alexsandrovp, says that Burn removes symlinks to its Package Cache directory. It doesn’t do that intentionally but does do work to ensure the cache is secure, which might make a symlink problematic. We decided Burn’s support for package cache redirection policy is the best approach.
SystemFolder does not resolve in the CustomAction element’s Directory attribute unless explicitly defined in Directory hierarchy, from @glytzhkof, points out one of the ways WiX overly reflects Windows Installer: Directories, even standard ones, must be defined in a package’s directory tree, even if you don’t take advantage of MSI’s support for uncompressed source directories. Rob volunteered to clean that up in WiX v4.
Summary information code page not set via the WixLocalization element?, from @glytzhkof, shows a missing feature in .wxl files: They cannot directly set the summary code page (Package/@SummaryCodepage) like it does for the package (Product/@Codepage). Rob, in his continuing volunteer spirit, took this on, to investigate whether the default for the summary code page should be the same as the package.