Today was all about the triage. Included in triage were three of the WIPs I wrote for the features I plan to implement in WiX v5. We didn't discuss them today but please do read them and comment. We'll likely discuss them at a future meeting, but as I write the meeting highlights, I get to draw extra attention to them here today. That's one of the powers of the pen.

Issue triage

  • NetFx Extension Always Produces Warning WIX5439 During Build, from @mark-monteiro, reports that using any of the .NET detection bundle variables defined in WixToolset.Netfx.wixext results in warnings saying that you shouldn't make variables that start with Wix because they're reserved for, well, WiX. Somebody didn't notice that these variables are, in fact, provided by the same smart, funny, and attractive people that created the message. I took this issue to fix, probably by turning the message into a compiler warning (again), in WiX v5.

  • WiX should correctly set the MSICHECKCRCS property, from @barnson, came about when, during a light bit of leisure reading in the Windows Installer SDK (as one does), I discovered the aforementioned property -- one that I'd never heard of before. A glitch in the matrix? A partially-repaired alternate timeline? Whatever the cause, apparently this new property is required for the CRC checking offered since MSI 1.0 to actually take effect. Neither Rob nor I find a lot of value in this particular check, though I admit that could be because it never actually did anything without this property. Anyway, WiX could automatically author this property when appropriate, so this issue is up for grabs for anyone interested.

  • Consider Ref suffix for more attributes, from @barnson, is, if you couldn't tell from the title, a suggestion that the WiX language should be consistent when an element or attribute creates references. For elements, we're consistent (though not perfectly so) in the many elements whose names end in -Ref. Some attributes follow the same rule (e.g., CustomAction/@BinaryRef) but others do not (e.g., Component/@Directory). The consensus in chat was that the -Ref suffix clarified what the attribute does and that had value. I wondered whether the extra clarification was more similar to the simple consistency of a language like Esperanto or the strict structure of Latin ("Romanes eunt domus!"). Rob suggested that getting more input on this, among other, topics was something he'd been considering in a wider survey of WiX users.

  • Culture-specific TargetPath preprocessor variable no longer works in WiX v4, from @doomlaur, reports that the TargetPath preprocessor variable created when using project references in an MSBuild project no longer has a culture-specific variant that WiX v3 created when building multiple localized MSI packages with localization files. We're not sure what's going on there but as there are easy workarounds, the issue is up for grabs for anyone willing to play in the guts of WiX's MSBuild targets.

  • RegisterFonts action is not added to the InstallExecuteSequence when fonts are being installed to the FontsFolder., from @kerrywicks, reports that authoring a TrueType font no longer automatically schedules the MSI standard action that registers the font. That is an unfortunate regression in WiX v4 that Rob has volunteered to fix.

  • Mismatch between File/@Id behavior and documentation, from @appel1, dares to suggest there is a slight documentation inaccuracy. After a brief review, I'm forced to conclude that the report is accurate and the doc is not. While WiX still defaults the component id to that of the component's key path, the approach in WiX v3 of defaulting the file id to the name of the file was fraught with peril, primarily that it meant you had to make special effort when you had more than one file with the same name. In WiX v4, when a File element has no explicit Id, WiX generates an id that is significantly less likely to collide. And now, in describing the issue, I have written more than enough to fix the schema documentation, so it's like I got paid to fix the doc. Win-win!

  • Level error messages do refer to Level attribute instead of Value attribute., from @robmen, is another report of a doc bug but slightly different in that this one is an error message, which, yes, is definitely documentation. Rob has the fix for this already out in a pull request.

  • IWindowsInstallerDecompileContext.TreatProductAsModule is borked, from @barnson, suggests that several core WiX developers have, over at least the past 15 years, reversed the meaning of fairly straightforward words. I might normally say that's inconceivable, but I know what that word means and as I'm one of those core WiX developers, I can assure you that it is conceivable. Basically, it does the opposite of what it says it does. So I plan to clean it up and, in WiX v5, figure out the right name.

  • WIP: WiX v5: Default feature, WIP: WiX v5: Default root directory, and WIP: WiX v5: Default major upgrade behavior and localized error message are all the WIPs for WiX v5 that I've written so far. The WIPs have the occasional "interesting" question in the "Considerations" sections that we should probably discuss. I'm going to decide (flip a coin) whether to finish my other WIPs first or ask Rob to schedule a WIP discussion during a near-future meeting.