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
MsiPackageto 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
MsiPackagefor 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
BundlePackagebut 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
Uninstallkey 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
light.exe makes no difference between comma and semicolon, from @wixbot, is, we decided, a documentation issue in how Votive describes cultures and how it works via MSBuild and the actual invocation of Light.exe (in WiX v3) and wix.exe (in v4).
Allow managed servers in
element, from @wixbot, is an ancient request to better support managed-code COM servers. You might think they aren't a big deal anymore but "not a big deal" doesn't mean "not a deal at all." We took this issue into WiX v4.x.
Enforce Windows Installer Limits, from @wixbot, is even older and comes from Derek, one of the First Generation WiX developers during the WiX v2 era. Perhaps out of a sense of nostalgia, Rob volunteered to implement some of the recommended checks in WiX v4.0.