Eight bits were enough for classic videogames but not enough to hold all the possible WiX Online Meeting numbers. Our next meeting will be number 256. Or will it wrap to 0? Find out on our new meeting day, Tuesday, 18-April. Until then, are we holding to our plan and shipping WiX v4 tomorrow? Read on for the thrilling conclusion! (Hint: Yes, yes we are.)
WiX v4 release plan
The WiX v4 release plan survived numerous encounters with the enemy (bugs, illness, issue investigations requiring slow-motion cameras) and this is the last update. We are on track to release WiX v4 tomorrow. See you then!
Issue triage
Wix Conversion - log message if TARGETDIR is used as a component's directory, Wix Conversion - IIS Certificate - BinaryKey is not converted to BinaryRef, Wix Conversion - Related Bundle - Action attribute value is not converted to lowercase, Wix Conversion - Condition - Inner text not moved to Condition attribute, and Wix convert - MsiPackage: remove SuppressSignatureVerification="yes", all from @wmanning, report some language conversions that
wix convertcould do a better job on (i.e., that we forgot). Rob fixed the bunch, given how unit-testable thewix convertcode is.MultiSzInsertString doesn't ensure double-null termination when called with the first value, from @nirbar, reports a bug in a function available in the native C/C++ library DUtil, the underpinnings of much of what you know and love about WiX, including the core toolset (even though most of it's written in C#) and Burn. It turns out the code in this function is substantially similar to the same function as shipped in WiX v2.0 but isn't widely used in WiX itself, so a bug, even one almost old enough to vote, is not out of the question. We moved this issue into the
v.Futuremilestone and will move it to the WiX v5 milestone when it opens up (shortly!).Force-load DLLs from System32 in Burn stub, from @barnson, is an inevitable result of reading a Raymond Chen blog post that includes the words "disease-ridden hot-tubs." Back when we were dealing with DLL hijacking mitigation for WiX v3.10.2, there was some grumbling that DLL hijacking is clearly a Windows problem that Windows should solve. Well, they did, and now that enough time has passed, all currently-supported versions of Windows have this solution available. The solution doesn't completely remove the need for the Burn clean room but is a good belt-and-suspenders approach. I volunteered to implement this in WiX v5.
MsuPackage documentation page misleadingly includes documentation about a Permanent attribute, from @icnocop, is a doc bug. Well, a former doc bug that I fixed.
wix4: heat fails to load dll which is linked to comctl32.dll 6.0, from @matbech, points out an issue with COM self-registration in Heat. While the 90s were a fine decade and gave us many fine things, COM self-reg was not one of them. This issue is now
up for grabs.wix.exe : error WIX0001: System.NullReferenceException at GenerateCacheIdFromHash and wix.exe : error WIX0001: System.NullReferenceException at HarvestPackage, both from @icnocop, report a similar bug for different package types in a bundle chain. Rob was able to find a central place to add error checking and avoid the embarrassment of a crash.
ExePackage is being rolled back even when it was not installed, from @icnocop, suggests not everyone prefers the new behavior in WiX v4 for
ExePackages during rollback. We'll keep this issue around to see what kind of feedback we get and what options are available for this particular problem.Comma in folder or file name of wixproj cause build error: [MSBuild]::MakeRelative, from @wmanning, complains that a comma that's part of the path to a .wixproj causes an error. Putting aside for the moment the very concept of commas in file and directory names, we're at the mercy of what's available in MSBuild. And just as this issue of Highlights was being sent to the printer, Rob found a targeted fix and sent a pull request that might well be the last change in WiX v4.
NetFx:DotNetCompatibilityCheck return values are off, from @kingfisher63, reports another doc bug that, like the proverbial parrot, is now off pining for the fjords. (It's fixed, is what I'm trying to say.)
DotNetCompatibilityCheck causes visible flashing of NetCoreCheck.exe window, from @13thirteen, is a bug that requires forensic analysis to reproduce, like expensive slow-motion cameras that I can now submit an expense report for. Fixing the bug was straightforward and Rob and Sean reviewed and approved.