Though we skipped the last meeting, we still would have only a handful of bugs...but somebody opened a bunch of WiX v4 bugs, which might provide a clue as to what that person is spending time with lately.
HarvestDirectory ItemGroup in the project works only on rebuild or clean build., from @skalinkin, points out that Heat.exe isn't triggered on an incremental build when using the
HarvestDirectoryitem in a .wixproj MSBuild project. It's not a trivial problem to solve for all the cases possible in harvesting, so we opened the issue in WiX v4.x for someone interested in improving Heat.exe to work on.
WiX v4 throws odd error when using
==operator, from @barnson, shows a pretty awful error message when "accidentally" trying to use a
==operator instead of the
=operator that WiX uses for equality. In the end, we decided that in WiX v4, both
==should be accepted.
WiX v4: Malformed preprocessor instructions crashy, from @barnson, demonstrates that a preprocessor error crashes with an unhandled exception. Those are bad so I submitted a pull request to capture the exception and present a normal error message instead.
Exceptions are reported as coming from wix.targets, from @barnson, reports that when exceptions aren't handled, the error message is attributed to
wix.targetsinstead of a source file and line number. Source files and line numbers are a much better way to track down what might have caused the unhandled exception in the first place, so we should report them whenever possible. We took this issue in WiX v4.0.
Error message MissingEntrySection is confusing when using intermediate files, from @barnson, points out a confusing error message when using one of the new features in WiX v4 to create an intermediate file after linking and before binding. (WiX v3 has something similar, to create a .wixout XML file rather than an .msi or other "normal" output.) I agreed to wordsmith the error message and create more-precise error messages where possible.
WixCop v4 should handle QtExec and WixCA renames, from @barnson, requests a feature to handle two changes in WiX v4: The
WixUtilExtensioncustom action DLL is now stored using Binary id
CAQuietExec64custom actions being renamed to
WixQuietExec64. I submitted a pull request to take care of those. Unfortunately, the
QtExecCmdTimeoutwas split into the platform-specific properties
WixQuietExec64CmdTimeoutso there's no guaranteed way of handling that particular rename. So while I'll always feel a little bit of shame for not being able to offer 100 percent automated conversion, it appears that use of
QtExecCmdTimeoutis rare, so I think I'll be able to live with myself.
NullReferenceException when trying to unset a version variable, from @pixafera, reports a crash when setting a
VersionVariablesvariable to null, which is how a string variable is reset using the managed-code layer for bootstrapper applications. We took the issue into WiX v4.x.
WixCop should ensure
Includeelements have the WiX v4 namespace, from @barnson, requests that WixCop apply the WiX v4
wxsnamespace to files that contain a root
Includeelement to be included with the
?include?preprocessor instruction. WiX v3 doesn't require that
Includeelements have the WiX v3 namespace but WiX v4 does. We took the issue in WiX v4.0.
Guidance for building arm MSIs for Windows, from @rakeshsinghranchi, wonders whether WiX supports the ARM or ARM64 architectures. Long ago, WiX v3 did support the 32-bit ARM architecture, though the only groups that used that support were teams within Visual Studio, to ship the Visual C++ redistributable and remote debugger for ARM devices like the original Surface RT tablet. Mere mortals couldn't ship Win32 ARM apps -- only software signed by Microsoft was allowed to run on such devices -- so public versions of WiX haven't supported ARM. Technically, the
-archswitch to Candle.exe supports
armas an argument, so you can build an .msi package that supports 32-bit ARM. But extensions, custom actions, and Burn aren't supported. And there's no support at all for ARM64. To get everything working will require a bit of effort. We took the issue in WiX v4.x.