Though we had only eight issues to triage, today's meeting was a bit super-sized. Most of it was due to a lengthy discussion on one particular issue, but Rob's telling of a truly awful dad joke also took time, especially when he tried a follow-up dad joke that we had to fact check in real time. No, I won't be repeating either one here; if you want bad puns, go ahead and watch the meeting.

New issue triage

  • Remove the 160 character limit for Custom Action Entry Points, from @Danielku15, is a feature request to relax the current limitation in the length of names of managed-code custom actions. In the vein of (the apocryphal) "640K ought to be enough for anyone," the length was set at 160 characters due to the way that the native-code host for the managed-code custom actions is built. That 160 characters includes both a file name and a type name, both of which can be long. It's possible to extend the length, though it's not just a minor recompile. We took the issue in v4.x for someone who wants to invest the time.

  • Set MsiPackage/@Visible='yes' when Permanent='yes', from @wixbot, is an issue from the newly-sentient wixbot -- I, for one, welcome our new robotic overlords. Oh wait, it was just Rob who'd accidentally logged in under the wixbot account. So Rob opened the bug and assigned it to himself, so this was a noncontroversial issue and not at all worrisome about Skynet.

  • Harvesting non-compressed BundlePackage should probably add payloads, from @rseanhall, broke our streak for quickly triaging issues. Though it might have looked almost straightforward an issue, it involved rather more philosophy and etymology than at first glance. When building a Burn bundle, WiX inspects MsiPackage to find the external cabs and files it contains, then generates the internal structures to include those files in the Burn manifest and (optionally) in the attached or detached containers that go along with the bundle. That inspection/generation process is usually called "harvesting," which is mildly confusing because we generally think of harvesting as the source-code generation performed by Heat.exe (in WiX v3). This issue is about performing the same kind of inspecting/generating that WiX does for an MsiPackage for the new BundlePackage. As bundles have more options than MSI packages for how payloads are packaged, we agreed we needed some control over which payloads WiX will choose to include. Sean volunteered to implement this in WiX v4.0.

  • BundlePackage should be able to fallback to the Package Cache, from @rseanhall, is also about BundlePackage but was much less controversial: Because Burn knows how to uninstall bundles, it isn't strictly necessary to have the bundle itself for uninstall. MSI packages work the same way: Burn just needs the product code (something it knows) to tell MSI to uninstall it. An interesting idea came out of the discussion: Burn could use the Uninstall key entry to look up the uninstall command line, which would allow Burn to be able to uninstall ExePackages that are built with other installer technologies, like Inno Setup and NSIS that use separate uninstaller executables. That might not be something we can squeeze into WiX v4.0, but we're all about injuring multiple avians with a single projectile where feasible.

  • Can't open solution contains wix project (Visual Studio 2022 Preview)., from @Hominis06, is sticking around for another meeting. Microsoft has contacted FireGiant about the underlying cause they've identified and are discussing how best to fix the problem. We'll see at our next meeting where it ended up.

Old issue triage