This week's meeting is the LAST WIX ONLINE MEETING EVER...on Fridays, that is. The times, they are a-changin'. For the better—read all the way to the end for details.
WiX v3.10.3 update
This week's update on WiX v3.10.3 is that there was a bit of progress from the GDI+ team on possible workarounds, though none we could implement in native-code Burn. So Rob's sticking with the progress being a good sign for another week.
Issue triage
Can't set IIS WebAppPool ManagedRuntimeVersion to "No Managed Code" #5226 is a request from @aroder to support a managed-codeless IIS app pool. It's not immediately clear how that's set up—native code not being a typical choice for web app developers—so this is something we took in WiX v4.0 where we can make a potentially breaking change.
Heat generates short path [!filename.dll] instead of full [#filename.dll] in case of disabled short file name creation #5225, from @leshy84, reports one of the more interesting Heat bugs we've seen in a while. When the file system is set up to disable the creation of short file names, Heat gets confused by an allegedly short file name that's the same as the long file name. (Short file names; how quaint.) We took this bug into WiX v3.x.
Cannot Find References #5223, opened by @MP012016, reports a problem building custom action projects using WiX v3.11. As there was a fairly serious bug affecting Votive in that first v3.11 build, we think that fix fixes this problem as well.
Burn's related/dependent bundle actions should be opt-in #5222 comes from me is the end result of working on a bug with related bundles this week. Prior to WiX v3.9, using a
RelatedBundleelement with anActionofDetect,add-on, orPatchwas a notification only: A custom BA could use the notification to take some action. In WiX v3.9 that was changed to automatically perform some actions. For example, uninstalling a patch bundle repairs its parent bundle. That's a "correctness in depth" behavior, as it's possible for these related bundles to change their parent bundles. Unfortunately, it can be an expensive behavior and it isn't always necessary. As before, a BA can change the behavior but as of today, it's not possible to opt out of the automatic behavior otherwise. We took this in WiX v4.0 to figure out the right behavior (opt in or opt out) and write a WIP with the design.Burn fails to pass ancestors to dependent bundles #5221, opened by yours truly, highlights my excitement for the week: When you mix and match versions of the Burn engine among related bundles, you can end up in an endless loop of, for example, add-on bundles repairing their dependent bundles and product bundles repairing their add-on bundles. The fix was simple. (As usualy, figuring out the problem was the hard part.) We decided to take this fix into WiX v3.10.3 when we release it.
Related bundle logging doesn't respect parent bundle /log switch #5220 is the final bug I reported this week and you might be sensing a theme: When installing a bundle that executes a related bundle, the related bundle's log doesn't respect the path specified in the original bundle's
/logswitch. If you're debugging a problem with related bundles, that's somewhat annoying. We took the bug into WiX v3.x.Documentation of "Restrictions for Patches" is broken #5219 is from @ThibaudSnld, reporting another doc page on the WiX Toolset web site that isn't being generated correctly. We took this issue into our Web milestone.
ConfigureUsers fails when it can't check the existence of the domain and no action is required #5217, from @nirbar, reports that a failure that should be ignored isn't, in fact, ignored. Bonus Internet points for including a pull request with a fix, which we reviewed later in the meeting.
light.exe returns -2146232576 in Windows 2016 Docker container #5213 came back with confirmation from @eerhardt that the problem is most likely with Windows containers and not WiX, as it affects other managed executables. So we closed this issue and look forward to running managed code in Windows containers.
Pull request review
This week's pull request comes from @nirbar and even though it had only three lines, it caused a fair bit of discussion. Well, one line did, about the particular error code being checked. As it was mostly unrelated to the root issue being fixed (also filed by @nirbar), consensus was that it should probably not be included in the change.
Meeting time
Rob proposed moving the normal meeting time to Tuesdays at 9:30 a.m. Pacific time (UTC-7/UTC-8) and having meetings alternate Tuesdays. The changes were met with general approval or at least minimal grumbling, with a few people asking about important issues coming up between meetings. Rob suggested that the wix-devs mailing list was perhaps an even better place for important issues, so more people than just those able to attend the online meetings live could participate. In the end, we decided to give it a try so the next WiX meeting—number 100!—will take place 8-March at 9:30 a.m. PST. See you then!