Rob suggested I would control how long today's meeting lasted because many of the issues were mine and some that weren't had questions from me anyway. I countered that idea by suggesting that almost all meetings could go very quickly if everyone just agreed with me. You might notice that we held today's meeting anyway.

WiX v4.0.2

After our last meeting, we said that:

After our last meeting, we said that:

WiX v4.0.2 will instead ship slightly before, during, and/or slightly after our next meeting in two weeks.

After today's meeting, we can confidently say that:

WiX v4.0.2 will instead ship slightly before, during, and/or slightly after our next meeting in two weeks.

After today's meeting, we can confidently say that:

WiX v4.0.2 will instead ship before our next meeting in two weeks, specifically by shipping it one week, on 12-Sep.

Personally, I'm looking forward to this part of the next meeting in two weeks.

Issue triage

  • WIP: WiX v5: Default major upgrade behavior and localized error message, from @barnson, is yet again subject to punting. We'll get to it, really.

  • Wix.exe deletes its own output folder if it's a symlink, from @vikukush, reports odd behavior when using a symbolic link as an output directory for a build. Happily, the issue includes a screen shot from fan-favorite tool Process Monitor from the Sysinternals toolkit. We put the issue up for grabs for file-system-level spelunking fun.

  • Firewall extension support for all Windows Vista+ firewall properties, from @chrisbednarski, is an issue associated with several pull requests implementing the included feature requests (which is the best kind of issue). It also serves as a spot during triage to discuss some interesting issues that are coming up in the development of WiX v5: So far, our planned features for WiX v5 are backward-compatible with WiX v4 so it's an option we're considering to not change the WiX schema namespace, meaning that your authoring for WiX v4 would compile as-is with WiX v5. That hasn't happened before with WiX, because prior major releases have made intentional breaking changes in the language and therefore required changes (usually automatic using WixCop or wix convert). For the firewall extension, however, @chrisbednarski is considering a change in behavior, which is something we've generally dealt with by having wix convert change the authoring to make it behave the way it used to. But if we keep the namespace the same, there's nothing to hint to the user that the behavior has changed. For now, we're agreeing that the namespace needs to change when the behavior changes and if we keep other namespaces the same as in WiX v4, that would be OK.

  • Generate component id when there is no valid keypath, from @barnson, requests that when a component doesn't have a key path resource to use as the default id, that WiX should generate the id, like it does almost everywhere else. This isn't generally a problem -- most components have things like files or registry values that provide ids the compiler can use as the default component id. Sometimes, however, you're in a special situation without a handy id and in those cases, WiX should generate one -- assuming that's possible. I took the issue to investigate.

  • WIP: WiX v5: Naked File, from @barnson, is a WIP for my favorite (so far!) WiX v5 feature: Naked files. In this case, "naked" means only that the file isn't wrapped in a component. We've done a lot of work over WiX's lifetime to make your average file very easy to author. (Here's a blog post I wrote back in 2009 about how simple we got it.) Most files aren't precious and don't require special handling: They're livestock, not pets. (We care about both but generally only pets get to live in the house and get scritches and cuddles.) (And if you do cuddle with livestock, hey, no judgment here!) For WiX v5, we want to eliminate the need to put a File element inside a Component element if the file doesn't require special handling beyond the most common scenarios. This WIP outlined that idea and called out a number of potential issues. Rob and I discussed them and concluded the advantages of the simple authoring you get when making naked files and the default-feature feature are simply too awesome (that's a quote!) (from me) to ignore. I have a few details to check out and will update the WIP and implement it soon.

  • Bundle/@IconSourceFile crashes when not an .ico file, from @barnson, reports the sad case of an unhandled exception (fancy-talk for a crash in .NET code) when supplying a non-icon file when WiX was expecting an icon. Crashes are never good and Rob volunteered to prevent this one.

  • build -outputType is ignored, from @robmen, is Rob disappointedly reporting that the ability to specify an output type from a WiX build separate from the extension of the output file is only partially implemented. Look, sometimes the squirrels are hard to ignore. Rob fixed this for WiX v5 and as we consider it a serious-enough bug, he also provided an implementation for WiX v4.0.2.