WiX Online Meeting #106 Highlights

WiX v3.10.3 update

The new WiX v3.10.3 release candidate build is available; please take a look, plug it into your build system, and help us verify v3.10.3 is ready to be released. Our new tentative release date is 4-July, the American holiday the Fourth of July (known elsewhere in the world as the Fourth of July).

Issue triage

• bootstrapper is deleted prematurely on upgrade, causing the install to fail, from @squirmy, is—we think—another instance of a bug that Sean fixed for WiX v3.10.3. We asked the reporter to try with the new RC build to verify.

• Mapping ExitCode 3010 for NetFx installer does not work, from @Laniusexcubitor, reports a problem when an ExePackage returns an HRESULT instead of a typical Win32 or custom error code. We don’t want to assume that arbitrary codes are comparable to HRESULTs, however— nothing requires arbitrary .exes to use any of the several standards for error codes that we have to choose from.

• Splash screen appears too late, from @cmlr72, points out that if you have a lot of payloads in your bundle, WiX v3.10.2’s introduction of the clean room means that it takes too long to show a splash screen. We took this bug in WiX v3.x to see if we can short-circuit the payload initialization when it’s not necessary.

• Regression in attached container issues in clean room and Extra argument in burn command line, both from @rseanhall, describe the remaining bugs scheduled for WiX v3.10.3 that Sean fixed in a pull request.

• Warn against using ServiceConfig and ServiceConfigFailureActions, from @barnson, came about after I noticed that the MsiConfigureServices action documentation says that this functionality is not working as expected. So, rather than fix it, we’re all supposed to ignore it. So we took this in WiX v3.11 to add a warning in the compiler.

• Burn built-in SystemFolder and System64Folder properties reversed, from @RGBradford, carries the shocking possibility that the built-in Burn variables SystemFolder and System64Folder are reversed. We took this bug in WiX v3.11 to investigate.

• Custom burn application throws exception when accessing .NET dll when uninstalling, from @slynch8, was one of the last WiX v3.10.3 bugs, another instance of the GDI+ bug that plagued us for too long. Sean fixed this bug too in a pull request.

• Doc explaining how to Install the .Net Framework has misleading detail, from @phillHgl, suggests that a particular page of the WiX documentation has a minor error. I graciously volunteered to right the wrong.

• error LGHT0103 : The system cannot find the file, from @prees1, reports a problem with not-quite-long paths with the twist that it isn’t the MAX_PATH 260-character limit Windows users are familiar with but a shorter limit when running WiX via Wine. As Wine isn’t something we WiX committers routinely (or ever) run, it’s not something we have any experience with or control over.

• All dialog description strings should end with a period (consistently), from @User5910, points out that some of the strings in the headers of the WixUI wizard pages are inconsistent in whether they end in periods. As it is mostly a documentation style question whether periods are correct, it must be resolved in the way of all writing-style questions, over absinthe and knife tricks (Ernest Hemingway only).

• Memory allocation test verifies incorrect variable, from @GregDomjan, reports what might just be a case of bad copying and/or pasting. A simple fix, which we will take in WiX v3.11.

• Engine.Variables ignores variable type, from @dsed, reports that the specializations the Engine class offers managed bootstrapper applications confusingly report that a particular variable is available, even if it’s not the right type. This is an example of a leaky, or at least an incomplete, abstraction. We took this issue into WiX v4.x for someone to perhaps come up with a better abstraction.

Pull request review

Today’s pull request review, from @lordjeb, implements a new feature to PermissionEx to set inheritable permissions on a folder or registry key. Because doing so would break patching in WiX v3.x, we could only take this change in WiX v4.0.