Eventually, we're going to have the WiX Online Meeting Musical Episode, because it's what all the cool shows do. But today was not that day. Instead, we spoke normally for our issue triage and a quick announcement of WiX v4.0.3.

WiX v4.0.3

Remember how WiX v4.0.2 featured prominently for months during the WiX Online Meetings? Yeah, we decided to skip that for WiX v4.0.3. It contains an important fix for inline directory authoring that was annoying me (and, indirectly, the FireGiant customer I was helping). So we found and fixed the bug, merged a couple of other bug fixes, and released WiX v4.0.3. It's up on NuGet.org and GitHub for your setup-building pleasure.

Issue triage

  • Please publish your signing fingerprint, from @rodwiddowson, requests posting details about the certificate used to sign WiX packages in another place to cross-check the signature on the WiX packages. Some might consider it overkill, but lots of big companies like to expect it from the open-source projects they get for free. Rob volunteered to investigate.

  • Wix.exe should have a compile command, from @barnson, was a gentle and humble request for a quick way of verifying the syntax of a WiX source file. The XSDs provide a rough pass on that but the WiX compiler does much more thorough verification. When you're working with big packages, a normal build might take several (or even many) minutes so having a way to more quickly check your authoring improves the "inner loop" of editing, building, and debugging. Rob is not a fan of the word compile, however -- so I closed this issue until I figure out a better way of describing the inner loop improvements I'm thinking of.

  • Native Dll's Excluded During Creation of Custom Action Dll, from @claybrooks, is describing a problem using native DLLs as dependencies of a managed-code custom action. It's probably not that the native DLLs are being excluded, just that they're not being included. WiX itself has this problem with its own native-code dependencies and there's build-time code involved making it work. The same type of additional code could probably be applied to the build of managed-code custom actions and we set the issue up for grabs for an interested party to investigate.

  • Custom compiler extension is included twice in the WiX build command, from @yuvnith, reports a problem using CompilerAdditionalOptions property being passed twice to the WiX build from an MSBuild project. Annoying bug and one that was small enough to fix in WiX v4.0.3.

  • Inline directory symbols in subsequent sections lost, from @robmen, is a simple title for a very frustrating bug. Was it so frustrating because it interrupted my work? Perhaps. After a lengthy session of remote pair debugging, Rob and I figured out the bug and I was magnanimous enough to let him fix it, which he did in WiX v4.0.3.

  • Shortcut using Anonymous Subdirectory generates ICE64 error, from @chrpai, reports a conundrum: You can use Subdirectory on a Shortcut element to create an ad-hoc directory for a shortcut but to pass ICE64, you must explicitly author a RemoveFolder element to clean up the directory (according to ICE64's somewhat arcane view). You can use a matching Subdirectory attribute on the RemoveFolder element in the same component, but that's repetitious. It's possible that an extension or maybe a new WiX language feature could automate all the tricky bits of shortcuts, so we opened this issue up for grabs.

  • Because it's deprecated, WiX should warn on VBScript custom actions, from @barnson, suggests that if Microsoft follows through on its announced plan to deprecate VBScript, WiX should emit a warning if you author a VBScript custom action. Some would argue script custom actions should already have emitted warnings but a missing VBScript guarantees your package will fail, so we figure that's definitely worth a warning. I volunteered to do just that.

  • WIP: WiX v5: Files, from @barnson, is my final planned feature for WiX v5: Adding support in the WiX language for installing files selected by wildcard. In other releases of WiX, that required the use of an external tool like Heat. Using primitives already built into WiX (like * component GUIDs from WiX v3 and Subdirectory in WiX v4), this kind of harvesting can now be safely done as a language primitive. If this appeals to you, please read the WIP and comment (or like and subscribe).