WiX: create and distribute SxS and flat style MSMs for developers#533
Open
compnerd wants to merge 20 commits into
Open
WiX: create and distribute SxS and flat style MSMs for developers#533compnerd wants to merge 20 commits into
compnerd wants to merge 20 commits into
Conversation
compnerd
force-pushed
the
msm
branch
2 times, most recently
from
2ce73a2 to
76b37b3
Compare
Member
Author
|
UI changes: |
compnerd
force-pushed
the
msm
branch
4 times, most recently
from
7f815d0 to
93a97fa
Compare
etcwilde
reviewed
Jun 15, 2026
etcwilde
left a comment
etcwilde
left a comment
Member
There was a problem hiding this comment.
You say "bound" and "unbound" and "flat" vs "SxS" a lot. The changes themselves look fine, but I don't know the definitions of these terms. Can you please include definitions of "bound" vs "unbound" in the readme. You do refer to the Side-by-Side strategy elsewhere in the readme, but I don't see anything tying SxS to the term "Swift-by-Side". The section describing what a Side-by-Side install is should at least contain a single SxS in it, ideally something like, "Side-by-Side (SxS) installs allow you to blah blah blah".
Please include a definition of "bound" and "unbound" in the context of a redistributable runtime.
Member
Author
Where should we add that explanation? Neither of these are really terms of art; I believe that the Microsoft naming is "shared assembly (WinSxS)" and "private assembly (app-local)" for the two models. https://devblogs.microsoft.com/cppblog/how-to-redistribute-the-visual-c-libraries-with-your-application/ is the closest thing to a reference I can find. |
Member
|
@compnerd and I talked about this offline. The issue is that we're already using "shared" vs "static" for the library type and "shared.shared" for a shared shared-assembly library is not meaningful. Instead of "shared" library, we'll use "dynamic" vs "static" and "shared" vs "private" to align with the existing terms. |
compnerd
force-pushed
the
msm
branch
5 times, most recently
from
59e52cd to
4e869d5
Compare
Most WiX projects consume shared.wixproj for common directories and localization, but runtime fragments define their own directory roots. They need a clear opt-out so the implicit shared reference does not create duplicate directory ownership or restore graph noise. Classify those projects by exact project identity, including shared.wixproj itself, so future runtime project renames update a visible list instead of a semicolon string search.
The shared runtime merge-module fragment only needs the selected RuntimeRoot. SDKRoot belongs to SDK packaging and is not referenced by the runtime fragment.
BlocksRuntime.dll is a runtime dependency alongside the other toolchain SxS DLLs, so place it in the same basename directory layout and include it in the SxSSwiftRuntime component group. Keep the BlocksRuntime import library in usr/lib so the SDK link surface does not change.
The SDK, runtime redistributable, and static dependency lists describe the same library set from different packaging perspectives. Replace the separate hand-maintained properties with one Module and Library metadata model that all WiX projects can project from. The metadata records platform availability, linkage availability, SDK grouping, runtime library names, and static runtime dependencies. This keeps each library named once while still covering Windows, Android, SDK component groups, runtime redistributables, and static merge modules. Model the known special cases in the metadata itself: Cxx and CxxStdlib provide static libraries in the shared-linkage SDK slice, while _FoundationCollections ships Swift module metadata without a library.
The existing runtime merge-module name used shared for the dynamic link model, which conflicts with the shared/private Win32 SxS assembly axis. Rename the dynamic runtime projects and MSM outputs to use dynamic so the filename describes the linkage axis consistently with static. Reserve shared and private for the installation-mode segment that later commits add to the redistributable MSM names.
Runtime merge module names need to identify linkage, Win32 SxS assembly mode, and architecture independently. Reserve the installation-mode position by naming the existing shared-mode outputs rtl.dynamic.shared.<arch>.msm and rtl.static.shared.<arch>.msm. This preserves the existing runtime MSM payloads while leaving a parallel namespace for private assembly variants.
Add private Win32 SxS assembly variants for both dynamic and static runtime merge modules. With the existing shared variants, the redistributables now cover linkage, installation mode, and architecture. Private variants install each DLL under its basename directory so applications can bind by assembly name and version without using the shared native assembly cache.
compnerd
force-pushed
the
msm
branch
6 times, most recently
from
ec7aac7 to
643c2c3
Compare
The Windows SDK bundle should let users choose which redistributable assembly mode to install for each architecture. Add separate Shared Win32 SxS Assemblies and Private Win32 SxS Assemblies options under the Windows SDK architecture nodes. Default private assemblies to selected and shared assemblies to unselected, then pass those choices to the dynamic and static MSM components in the Windows platform MSI.
HelloMergeModule is a sample for consuming runtime merge modules, so it should build in the broadly usable dual-scope configuration by default. Use the private runtime MSM unless the sample explicitly opts into the shared native assembly cache. When the sample selects the shared MSM, make the package per-machine by default because shared native assemblies require machine scope.
Signing and Win32 assembly packaging both rely on executables from the Windows SDK. Keep the SDK directory lookup in one place so the signing, manifest, and catalog targets agree on the selected SDK and host tool architecture.
Signing requires signtool.exe from the Windows SDK. Report a direct configuration error when the tool cannot be resolved, instead of allowing signing commands to fail later with a less useful Exec error.
Shared Win32 assembly packaging depends on mt.exe and makecat.exe from the Windows SDK. Diagnose missing tools when the cataloging target is used so package failures report the missing prerequisite directly.
Shared-mode RTL packages install DLLs as cataloged Win32 assemblies in the shared native assembly cache. Windows Installer requires these assemblies to be authored with manifest and catalog payloads that identify and protect each DLL, so the shared dynamic and static RTL packages carry those payloads together with each assembly DLL. The shared RTL MSI is per-machine because global Win32 assemblies are not valid in a per-user package. Private-mode runtime packages remain in the basename directory layout for application-local binding. Assembly components use explicit stable GUIDs for unversioned DLL key paths and WiX-generated GUIDs for versioned runtime DLLs, avoiding synthetic file versions while keeping component identity stable.
The Windows installer README had drifted from the current bundle and package authoring. Update stale file paths, option and upgrade-code names, toolchain variant values, Android architecture spelling, and SxS/cleanup descriptions so the documentation matches the installer sources.
The Python MSI presented its feature as the IDE asserts package and listed Python 3.10-specific payload filenames even though the build takes PythonVersion as input. Keep the package and feature on the Embedded Python product name, and keep ABI-specific payload filenames aligned with PythonVersion so Python updates do not need another metadata fix.
The Android platform MSI had its own upgrade code but did not participate in the shared side-by-side upgrade strategy. Include it in the same minor-release upgrade policy as the Windows platform package so point releases replace the matching Android platform release.
The sidebar source asset is an SVG used to generate resized banner images, but its filename used a misspelled .svvg extension. Rename it to .svg so the source asset is discoverable by extension-aware tools without changing the generated PNG consumed by the bundle.
Windows and Android platform packages compile the same shared SDK header fragments. Move that common Compile item list into one imported props file so adding or removing a shared fragment updates both platform packages together.
The bundle UI carried separate copies of the same platform and SDK tree metadata through MSBuild constants, WiX variables, and BAF. Keep package availability decisions in MSBuild, collapse repeated WiX variables into architecture loops, and represent BAF tree rows as platform plus architecture metadata so each SDK row has one source of truth.
The Android and Windows platform packages pass the same SDK property shape for each architecture, with Windows adding matching redist properties. Collapse those repeated property groups by architecture so architecture changes update one list while package-specific conditions and download URLs stay explicit.
etcwilde
approved these changes
Jun 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a new system for managing runtime libraries and Win32 assemblies in the Windows build process, with a focus on modularity and configurability. It adds new MSBuild property and target files to define, select, and generate runtime libraries and their associated Win32 assemblies, and updates the build logic to integrate these changes.
Runtime Library Management Enhancements
RuntimeLibraries.propsandRuntimeLibraries.targetsto define runtime modules/libraries and automate the selection and propagation of runtime library constants and dependencies based on project and platform. These files introduce structured definitions for SDK and DeveloperTools modules and libraries, and automate the generation of relevant MSBuild properties and constants. [1] [2]Directory.Build.propsandDirectory.Build.targetsto import the new runtime library property and target files when building.wixprojprojects, ensuring that the new logic is applied to installer projects. [1] [2]Win32 Assembly Generation Automation
RuntimeWin32Assemblies.targetsto automate the generation of Win32 assemblies for runtime libraries, including copying DLLs, generating manifests and catalog files, and optionally signing outputs. This target is conditionally run for shared installation modes and relevant runtime library projects.Directory.Build.targetsto import the newRuntimeWin32Assemblies.targetsfor.wixprojprojects, integrating Win32 assembly generation into the overall build process.Runtime Package List and Constants Update
Directory.Build.targetsto include dynamic libraries (rtl.dynamic.libandrtl.dynamic.msm) instead of shared ones, reflecting the new modular runtime structure. Also, added logic to propagate theRuntimeLibraryInstallationModeas a MSBuild define constant.These changes collectively improve the flexibility, maintainability, and automation of handling runtime libraries and their Win32 assemblies in the Windows build pipeline.
Fixes: swiftlang/swift#88413