WiX Online Meeting 297 Highlights

Issue triage

• Decide on best behavior for Files with relative paths, from @barnson, is an issue I opened after last month’s meeting to give me time to think about how best to handle relative paths in the Files element. I took the time, hardly procrastinating at all, and decided that the only behavior that made sense was to always treat relative paths as relative to the source .wxs file. That made me sad, because I really wanted the default to be relative to the more common executable files, but I bought myself something nice so now I feel better.

• How to Create an MSP file using the PatchCreation property in WiX v6, from @freezinglo, questions how to use WiX v6 to create some really-old-school .pcp files to generate patches. The answer is “you don’t.” The new Patch element in WiX v4 and later is oodles better (that’s a technical term) and can do everything .pcp files did and more. Rob volunteered to make a more actionable error message.

• Related Patch Bundle with msp package doesn’t uninstall when Parent bundle is uninstalled, from @JasonLow8, reports some unexpected behavior using patch bundles. I volunteered to investigate.

• DirectorySearch/@Id is required, from @barnson, is one of several issues this month that came from work I’m doing at FireGiant. This one was just a surprise: A mandatory Id attribute?! I thought those were all removed in the Great Id Purge of 2023. Apparently, one escaped, so I volunteered to squish it.

• Read-only target .msi throws confusing exception, from @barnson, came from a short attention span, forgetting I’d marked an .msi read-only and opened it in Orca. It turns out WiX crashes with a fairly scary exception message in both those cases. Rob volunteered to make it more soothing.

• DirectorySearch and FileSearch complain (but succeed) when given a >8.3 name, from @barnson, is another issue spawning from my AppSearch work. I noticed in an MSI log that when using a “long” file or directory name, MSI would emit a message that the name was “not a valid short file name.” But it worked anyway. Then the documentation was rather wishy-washy, saying that a DirectorySearch “can” specify a combination short and long name. (Nothing either way on a FileSearch.) Because there’s no clear “right” answer, we sent the issue to the up for grabs bucket.

• Pipe has been ended when writing path longer than 255 (MAX_PATH issue), from @NokiDev, is another in a long line of unsuccessful attempts to use very long path names. (Note that we have “short” names up to eight characters and three for an extension, “long” names up to 260 total characters, and “very long” names bigger than 260 characters. Personally, 8.3 is an old favorite.) Very long path names have never been supported in WiX, starting with the lack of support for them in .NET Framework and leading to the lack of support for them in old MSI and CAB API functions. However, in WiX v4 most of those APIs are now handled by a native component that might be amenable to working around those limitations. Rob volunteered to investigate and, worst case, replace the exception with a friendly error message.

• x64 bundle from wix4/6 cannot be detected by wix3 (x86) bundle, from @svg2003, points out that because bundles built with WiX v3 were always 32-bit, they can’t see the bundle registration made by 64-bit bundles built with modern WiX. Those bundles know to search both 32-bit and 64-bit bundle registration but to allow WiX v3 to see those bundles, we’d need 64-bit bundles to also write 32-bit registration. That’s pretty straightforward, so we opened the issue up for grabs.

• Bundle cannot start if UAC is disabled due to wrong elevation mode detection, from @svg2003, reports that a standard user running on a machine with UAC disabled cannot launch a bundle. The issue was reported against WiX v4.0.6, which is out of community support, and the error is in creating the clean room, which was removed thanks to out-of-process bootstrapper applications in WiX v5. Rob has volunteered to investigate.

• Invalid FileSearch MinDate/MaxDate values result in an exception, from @barnson, is the final in my series of AppSearch-related issues---for this month, anyway. Due to the bit-squeezing method Windows Installer uses to store dates, dates in a FileSearch have limited range. Specifically, dates before 1980 aren’t supported. Apparently, nothing good happened before 1980. As is tradition, because I reported the issue, I happily volunteered and did not require any coercion at all to introduce a good error message.

• When authoring patches using .msi files in WiX v6, error occurred, from @li-xingquan-pnt, reports that packages built with WiX v3 can’t be patched after converting them to be built with WiX v6. That is correct. WiX has never supported building packages with different major versions because patches are sensitive to changes that have happened and will continue to happen between major versions, like different id generation algorithms. So, as the apocryphal doctor allegedly said, “don’t do that.”