Refactor WiX installer projects #215
Conversation
## Deduplication - Move common .wixproj content to Directory.Build.props and Directory.Build.targets. - Move common authoring to a shared .wixlib project. - Add localization file for common strings. - Use ComponentGroup/@Directory for default component directories. ## Simplification - Move CompressionLevel into Directory.Build.props. - Have Directory.Build.props import <user>.props (say, to override CompressionLevel for faster local builds). - Remove Id attributes from resources that aren't explicitly referenced. - Remove redundant/irrelevant attributes (e.g., File/@keypath). - Use `ProjectReference`s to manage build order and bind paths, including three flavors of SDK. - Remove MSI UI as the bundle UI replaces it.
better support NuGet package restore. - With projects in subdirectories, enabled automatic project items for compilation and localization. - Added project references to bundle project to get proper build order. - Deduplicate project references to shared.wixproj. - Remove Feature/@ConfigurableDirectory because individual features can't be moved to other directories (just the root).
- Localize MSI_LOCATION to bundle. - Undo custom bundle output name for compatibility. - Fix whitespace and EOF. - Conditionalize stuff not yet available on Arm64. - Harvest with stable GUIDs instead of generated GUIDs.
| Version="$(var.ProductVersion)" | ||
| Manufacturer="swift.org" | ||
| Compressed="$(IsBundleCompressed)" | ||
| UpgradeCode="710F1827-DA4A-4BF4-BDCE-D5F2D7C0DEF2"> |
There was a problem hiding this comment.
Is it no problem to have the same UpgradeCode for both architectures?
Would that prevent installing both the arm64 and amd64 binaries on an arm64 machine (which supports amd64 emulation)? (maybe not a real scenario, asking to understand)
There was a problem hiding this comment.
You're right; either architecture would upgrade its own and the other on an Arm64 machine. If making them side-by-side is a real scenario, then they need their own upgrade codes and some directory reorganization so they don't overlap. Windows Installer supports overlap for non-PE files like SDK headers but all the host binaries would need architecture-specific directories to avoid overlap. We can figure out the directories as part of the per-user work if you want it -- especially as we're already messing around with how the tree is organized by moving it out of Program Files.
There was a problem hiding this comment.
@compnerd Do you think we care about this?
There was a problem hiding this comment.
I can imagine that we might care about it to a certain extent. I don't think that this is critical or particularly important at this time.
...into cli and dbg, respectively, and: - Add placeholder MajorUpgrades (pending new upgrade strategy). - Add shared SystemToolsEnvironmentVariables component.
|
Kicked off a new CI run, 🤞 it passes! |
|
The build failed: https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/704/consoleText Seems that the path to the clang headers is getting truncated @barnson? |
|
D'oh. Fixed. |
|
New run kicked off: https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/705/ |
|
Embedded cabinets match what build-windows-toolchain.bat expects. We should revisit if we can prefer the bundle over the MSIs. |
|
💯 |
|
@barnson why is installer.exe 640MB? That seems like a pretty hefty size increase from 399MB. Additionally, since this now requires the license agreement checkbox, can the install still be done unattended? |
`MediaTemplate` defaults to 200MB of source payloads for splitting into separate cabinets. WiX's "smart cabbing" feature works within a cabinet, eliminating duplicates -- but doesn't work across cabinets. So we're not getting rid of as much redundancy. We could adjust the 200MB threshold, but let's just explicitly author that we want a single cabinet to get the best possible compression (at least for a cabinet).
|
Silent install doesn't require any gesture to agree with the EULA. Is the checkbox needed? I can default the checkbox to checked or get rid of it entirely when I do the custom theme. |
No, I don't think that the checkbox is needed. We can deal with that aspect later :). |
|
https://ci-external.swift.org/job/swift-PR-build-toolchain-windows/708/ build succeeded, seems reasonable (should smoke test it). Need to wait for the parallel change to be ready before we can merge this. |
No description provided.