In a normal year, today would have been Tax Day here in the United States. Of course, this year, like last year, isn't normal, so Tax Day was postponed. Speaking of dates, read on for Rob's announcement of our planned date for the release of WiX v4 Preview Zero!

Issue triage

  • Introduce StandardDirectory to reference standard directories, from @robmen, was already implemented and closed since our last meeting. Here's how it works: Instead of using <DirectoryRef Id="ProgramFiles64Folder> to get your product installed to Program Files, you can now use <StandardDirectory Id="ProgramFiles64Folder> -- and the Id attribute will be an enumeration of all the standard directories WiX knows about, meaning that you'll eventually be able to get a nice drop-down of allowed values. Less guessing whether it's ProgramFiles64Folder or ProgramFilesFolder64.

  • Source name always written to Directory table, even when identical to target name, from @barnson, was a simple bug that copied the source and target names of a directory when writing the .msi package. As the source name is almost always the same as the target name, MSI lets you drop the source name when they match. Rob fixed the bug less than an hour after I opened it!

  • IEnumerable<> should not be sent to Extensions, from @rseanhall, is the result of some discussion about how we should expose collection types from the WiX extensibility and data assemblies. For example, the IntermediateSection.Symbols property used to be of type IList but Rob recently changed it to be of type IReadOnlyCollection. IList exposes more functionality over a section's symbols than we want to promise: For example, IList lets you add and remove symbols; we'd rather "encourage" the use of the IntermediateSection.AddSymbol and IntermediateSection.RemoveSymbol methods to allow for validation or other side effects. Rob agreed to take this issue in WiX v4 Preview Zero.

  • Migrate compiler/backend specific errors/warnings to the compiler or appropriate backend, from @robmen, is another "hey, let's look at what we've learned and adapt" issue. Today, almost all WiX v4 messages are methods in the WixToolset.Data assembly so they can be reused by every component in WiX and any WiX extension. However, many of the messages in WixToolset.Data are absolutely specific to the innards of WiX and aren't useful outside the core WiX code. So this is a nice improvement but we don't believe it's critical for WiX v4.0. Therefore, we took this as the very first issue in the v.Next milestone for the next major release of WiX.

  • EnsureTable should be available for any MSI table, from @barnson, is a bug stemming from a recent change that prevented the use of the EnsureTable element to force the ModuleSignature table to be included in an .msi package that wouldn't otherwise have it. As that's an extremely edgy edge case, we agreed it should be fixed in WiX v4.0 but wasn't needed for WiX v4 Preview Zero.

  • wix convert does not report errors if converted files can't be written, from @barnson, reports a regression in the move from WiX v3's wixcop tool to its new incarnation in WiX v4's wix convert command. Specifically, if a file being converted to WiX v4's schema can't be written back to, there's no error message or any other indication it wasn't converted. As we want the conversion experience to be as delightful as possible, we agreed this should be fixed for WiX v4 Preview Zero.

  • !(bind.packageDescription.PackageId) doesn't resolve, from @rseanhall, is a hopefully simple bug in the Burn build backend that isn't populating the binder variables for packages in a bundle. Rob took this issue for WiX v4 Preview Zero.

WiX v4 design discussion

  • Burn will use incorrect package if local covers a large rewrite Sean is doing in Burn around the acquisition and caching of payloads. These are both fairly complex areas in Burn: acquisition covers everything from extracting files out of a container to downloading them over the Internet and caching includes hash verification that's a big part of Burn's security model. Sean and Rob both seem confident the new design is more consistent and corrects a couple of flaws in the Burn v3 API design.

  • Burn should have an option to cache packages that aren't needed for install but will be needed for repair is a subcomponent of the work Sean's doing about caching in Burn v4. We discussed the issue at length last month and Sean brought it up today to discuss the idea of having caching be controlled by bundle authoring. A binary choice works well with conditions in bundle authoring, like InstallCondition. It doesn't work well (or at all) when you have a choice of three options, like the keep, remove, and force options for Cache. I took the stance that because the bootstrapper application can control caching completely, we didn't need to expose every Burn feature solely via authoring, especially for the (I asserted) low-priority case of wanting to control caching at runtime. That prompted a philosophical discussion about the complexity of mixing declarative bundle authoring and tweaking BAs to introduce imperative code and the need for better layering in BAs. From that discussion, an idea popped into my head about layering BAs like sandwiches, and I scribbled down some ideas. It was either brilliant or I was hungry.

WiX v4 Preview Zero

As we're quickly approaching both the aspirational date we embraced for WiX v4 Preview Zero, as well as the remaining open issues for it, let's discuss what WiX v4 Preview Zero will look like:

  • wix.exe will be distributed as a .NET tool. That requires the .NET Core SDK and a simple command to install the WiX .NET tool from NuGet.org.
  • In Preview Zero, MSI packages, merge modules, and Burn bundles will be supported.
  • The Util, Bal, UI, and Netfx WiX extensions will be supported.
  • The wix convert command will support converting WiX authoring from the v3 schema to the v4 schema.

In Preview Zero, .wixproj MSBuild projects and creating patches will not be supported. Now that's not to say MSBuild and patches aren't present in the toolset but rather than we know they have significant holes and we want to focus Preview Zero on the new wix.exe experience, because we're confident it has fewer and smaller holes in functionality.

There are currently 10 open issues assigned to Preview Zero but most of them are well understood so as long as random chance continues to operate in our favor, we're hopeful that we can release Preview Zero on the international holiday of May 4th. But don't worry -- if we miss 4-May, there are plenty of other holidays in May.