Today we had more than a dozen issues to triage and two design questions to discuss. Guess which took the most time?

Issue triage

  • Patch can't be created when MSI got file from wixext, from @rseanhall, prompted Rob to investigate the diffing process for patching a bit more. That resulted in Rob opening WIP: Source files from MSIs during patching, to make explicit the need for a WiX v4 equivalent to the work I did in Melt.exe in WiX v3. We agreed it's the right approach and Rob volunteered to write a WIP after WiX v4.0 Preview Zero.

  • Wix extension slows down the visual studio, from @sj6219, is the first time we've seen a report of Votive causing Visual Studio's find-in-files command to become slow. It's not a general problem, at least with the Professional and Enterprise editions of Visual Studio -- otherwise I'd be the first complaining.

  • Don't silently ignore payloads that are in multiple containers, from @rseanhall, presents a combination bug and feature request: The WiX language supports having the same payload in multiple containers but doing so didn't work in WiX v3 (where "didn't work" means "crashes") and currently doesn't work in WiX v4 -- but could. We took the issue into WiX v4 to either implement what's possible in the language or emit a warning or error that it's not supported.

  • LayoutOnly payload information is wrong in BootstrapperApplicationData.xml , from @rseanhall, is another bug from Sean's current deep dive into Burn. Though it appears to not affect actual functionality, it's disturbing to see bad data in the Burn manifest. We decided it wouldn't block WiX v4.0 Preview Zero.

  • WIP: Improved patch filtering, from @robmen, is the other patch issue Rob opened for this meeting, this one on how "patch filtering" works. Patch filtering is how to select explicit resources for a patch, rather than the default of "everything that changed between the old and new packages." In WiX v3, patch filtering works at the section level, meaning that a ComponentRef (for example) brings in all the other resources in the section (usually Fragment) the component was authored in. That usually leads to more changes in the patch than expected. Conversely, WiX v3 patch filtering does not bring in the related resources that you'd typically expect. For example, CustomActionRef includes only the custom action, not its DLL -- for that, you need to also include BinaryRef. Rob proposes (and will write a WIP to reflect that) to combine the best of the two behaviors: Patch filtering in WiX v4 will include related resources by default and not the whole content of every fragment.

  • Include all files of WixUI dialogs to SDK, from @Beautyod, requests that the WiX authoring for all the dialogs in the WixUI dialog library be included. Given that in WiX v4, NuGet packages are the typical way of acquiring WiX extensions, these extra files don't really have a place. Luckily, they live in a Git repo and GitHub lets us point to them individually and lets you download a whole repo as a .zip file without having to run even a single git.exe command line. (Though in 2021, can anyone avoid Git even if they wanted to?)

  • RelatedBundle/@Action="Detect" should support setting a variable, from @barnson, came about from my work on a bundle that includes another bundle in its chain. (This happens every time you install, for example, the Visual C++ runtime redistributable, which has been a Burn bundle since 2012.) As it's important to specify a DetectCondition for every ExePackage to reduce install time, I wanted to detect whether the included bundle was already installed. Today, that requires a custom bootstrapper application (or a BAFunctions.dll using WixStdBA). If the Burn engine were to set a variable with the version of a bundle when processing RelatedBundle entries, the DetectCondition expression would be straightforward to write. I took this issue to write a WIP describing the feature and, schedules willing, to implement it in WiX v4.0.

  • The DownloadUrl placeholders aren't being replaced, from @rseanhall, is a regression in how payload DownloadUrls handle substitutions to parameterize the URL with package and payload ids and names. Rob volunteered to fix this issue in WiX v4.0 Preview Zero.

  • Including package with uncompressed payload into a detached container causes cab creation to fail, from @rseanhall, is another regression from WiX v3 behavior around detached containers (an interesting but rarely-used feature of Burn that lets you put multiple payloads in a compressed container external to the bundle). We took the issue into WiX v4.0 but given the rarity of detached containers, we decided it wouldn't block WiX v4.0 Preview Zero.

  • Uncompressed bundle payloads are not copied to output folder for msbuild projects, from @rseanhall, reports what Rob declared is a bug in the current MSBuild targets. As Rob is planning on overhauling them after WiX v4.0 Preview Zero, we took this issue into WiX v4.0.

  • Building bundles with files that are bigger than supported should be a warning or error, from @rseanhall, correctly points out that there are limits in the Windows Installer and cabinet file formats that should be reported as early as possible. That usually means trying to build a huge output and failing, hopefully with an actionable error message ("don't do that" or better). So let's try to do that in WiX v4.0.

  • The BA should not receive unknown PackageIds during Plan or Apply., from @rseanhall, demonstrates via a bug fix that when installing update bundles, the bootstrapper application will see a package id during execution that it didn't see during Burn's detect or plan phases. That led to the now-fixed crash in WixStdBA. Sean suggests sending details about such packages with context so the BA knows it's getting details about an update bundle. We took the issue into WiX v4.0.

WiX v4 design discussion

Today, we tackled two design questions:

  1. Should we update to .NET Core 3.1 for the handful of netcoreapp projects in WiX v4, or should we stick with .NET Core 2.1, which will be unsupported after August this year? Yes, we should update. Question answered!
  2. The innocuous-sounding long-standing bug Cannot specify Component/@Directory when nested under ComponentGroup with Directory specified. Naturally, the discussion for this issue lasted for an hour and a half.

The root of that issue is that in WiX v3, we added the ability for a ComponentGroup to specify a directory for all child Component elements. However, individual Component elements cannot override the ComponentGroup's directory. We're in agreement that should be allowed, but WiX v4 complicates matters a bit. One of the very first features in WiX v4 was inline directory syntax, which allows you to create subdirectories in-place, without needing to create corresponding Directory authoring. Windows Installer still requires those Directory table rows, of course, but with inline directory syntax, WiX takes care of those annoying details.

Today, the syntax looks like this:

<Component Directory="ProgramFilesFolder:\CompanyName\ProductName">

Because WiX v4 now supplies well-known directories like ProgramFilesFolder, the inline directory syntax string ProgramFilesFolder:\CompanyName\ProductName requires no Directory elements.

Inline directory syntax intersects with the default ComponentGroup directory because of a natural thought that when a Component specifies a directory, it's inline directory syntax for a subdirectory of the directory specified in the ComponentGroup. The problem there is that with a single attribute (Directory), there's no way to distinguish between inline directory syntax for a subdirectory and the id of a Directory defined elsewhere.

Lots of discussion ensues. We ended up with a combination of all the ideas we'd discussed: The Directory attribute would continue to function as it does in WiX v3: The attribute specifies a reference to the id for an existing Directory element. A new Subdirectory attribute lets you specify inline directory syntax for a subdirectory under the directory referenced by the Directory attribute:

<Component Directory="ProgramFilesFolder" Subdirectory="CompanyName\ProductName">
...

It works really well when you combine multiple subdirectories:

<ComponentGroup Directory="ProgramFilesFolder" Subdirectory="CompanyName\ProductName">
  <Component Subdirectory="bin">
  ...

Rob's going to implement this design for WiX v4.0 Preview Zero.