mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
e932fe6e61
## Summary of the Pull Request Two related installer changes to (1) eliminate genuinely-unused dependencies and (2) deduplicate shared WinAppSDK files between `<install>\` and `<install>\WinUI3Apps\` to shrink the installer download. ### 1. Remove unused dependencies (~11 MB savings per output location) - **System.Data.SqlClient**: Removed from MouseWithoutBorders projects and the central `Directory.Packages.props` pin. It was a transitive dependency of `Microsoft.Windows.Compatibility` but PowerToys has zero SQL database usage. - **Unused `using` import**: Removed `using System.ServiceModel.Channels` from MouseWithoutBorders `Program.cs` (no WCF usage). - **MFC / C++ AMP / OpenMP DLLs**: Added `RemoveUnusedVCRuntimeDlls` target in `Directory.Build.targets` to clean up `mfc140*`, `mfcm140*`, `vcamp140*`, and `vcomp140*` DLLs that leak from the VC++ Redistributable tree but are not imported by any PowerToys binary (verified with `dumpbin /dependents` across all installed binaries). Also excluded MFC DLLs from installer file collection. ### 2. WinAppSDK file deduplication (build-time only; install-time uses copy) **Background**: The `WinUI3Apps` subfolder must remain a real directory because MSIX sparse package registration applies DACL changes to the `ExternalLocation` folder (PR #47177). Flattening is not viable. **Build-time** (`generateAllFileComponents.ps1`): computes the SHA256 intersection of root and `WinUI3Apps` files, and for each file that is also present in the BaseApplications WXS file list, removes the duplicate from the WinUI3Apps WXS component list and writes its name to a `hardlinks.txt` manifest. The BaseApplications cross-check ensures we never deduplicate a file the MSI does not actually deploy at the install root, which would otherwise leave both copies missing post-install. The manifest is written as UTF-8 without BOM (via `[System.IO.File]::WriteAllLines` with `UTF8Encoding($false)`) so its encoding is identical regardless of the build host's PowerShell version. This step produces the **MSI download-size win** (~97 MB smaller cab; LZX:21 was already deduplicating most byte-identical content automatically inside the cab). **Install-time** (`CreateWinAppSDKHardlinksCA` custom action): - Reads `hardlinks.txt` after `InstallFiles` as a raw byte stream and converts each line to a `std::wstring` via `MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS, ...)`. Avoids `std::wifstream`'s ANSI-codepage codecvt so non-ASCII paths can never be silently mangled. - For each entry, computes `(installDir / fileName).lexically_normal()` and `(winui3Dir / fileName).lexically_normal()`, then verifies via `std::mismatch` that each resolved path is still rooted at its respective folder. Manifest entries containing `..`, absolute paths, or alternate-stream syntax are logged and skipped. - Materialises each validated entry from `<install>\<name>` into `<install>\WinUI3Apps\<name>` via `fs::copy_file` (overwrite_existing). - Reports the per-file copy / failure counts to the install log. If every entry failed (`created == 0 && failed > 0`), the CA escalates to `E_FAIL` so the install does not silently succeed with an unusable WinUI3Apps tree. `DeleteWinAppSDKHardlinksCA` removes the materialised copies before `RemoveFiles` on uninstall, using the same UTF-8 reader and per-entry containment check. **WiX sequencing**: `CreateWinAppSDKHardlinks` runs `After="InstallFiles"` with `Condition="NOT Installed OR WIX_UPGRADE_DETECTED OR REINSTALL"` so a `msiexec /fa` repair refreshes the deduplicated copies (otherwise `RemoveFiles` would orphan them). #### Why copy and not hard-link A hard-linked variant of this CA was originally proposed but caused a Monaco preview-handler regression. Hard-links share an NTFS inode (and therefore one DACL) between `<install>\<file>` and `<install>\WinUI3Apps\<file>`. The MSIX sparse-package registrations for PowerRename / ImageResizer / FileLocksmith / NewPlus run after the dedup CA and propagate the `WinUI3Apps` parent's rich DACL (Capability SID, 5× Package SIDs, 5× conditional SYSAPPID ACE, RC SID) onto the shared inode. The root path then also exposes the rich DACL, which trips a kernel "stricter access evaluation" path that blocks the LOW-IL `prevhost.exe` from `LoadLibrary`-ing `hostfxr.dll` (and the rest of the .NET runtime), turning the Monaco preview pane blank for `.json` / `.md` / `.cs` / `.xaml` / `.svg` / `.xml` files. `fs::copy_file` creates a **fresh inode** for the WinUI3Apps copy. The root inode keeps its simple DACL (`SY:F + BA:F + owner:F` + inherited `BU:RX`) so LOW-IL `prevhost.exe` can still load it — Monaco preview works. The WinUI3Apps copy inherits the WinUI3Apps parent's rich DACL via normal NTFS inheritance (matches 0.99.1 behaviour exactly) — MSIX context-menu shells continue to work. #### Trade-off | Metric | Hard-link variant (rejected) | This PR (file copy) | 0.99.1 (no dedup) | |---|---|---|---| | MSI size | ~296 MB | ~296 MB | ~393 MB | | On-disk after install | ~2,475 MB | ~2,772 MB | ~2,772 MB | | DACL contamination risk | YES (broke Monaco) | NO | NO | The on-disk savings (~297 MB) are given up in exchange for eliminating the DACL contamination risk; the **installer download savings (~97 MB)** are preserved by the build-time WiX/cab dedup. #### Edge cases handled - Empty duplicate list: `hardlinks.txt` always written, CA handles empty. - All files duplicated: `Generate-FileComponents` returns early for empty list. - File stripped from BaseApplications by an earlier build step: BaseApplications cross-check skips it during dedup so neither copy goes missing. - Manifest entry escapes install root (`..`, absolute path): rejected per-entry, install continues. - Manifest line is non-UTF-8: rejected per-entry, install continues. - Source missing at install time: per-entry skip, install continues. - All copies fail: install aborts loudly via `E_FAIL` (catastrophic-case escalation). - Upgrade or `msiexec /fa` repair: CA fires (`NOT Installed OR WIX_UPGRADE_DETECTED OR REINSTALL`). **MSI repair risk**: Burn bundle uses `SuppressRepair=yes` and `MajorUpgrade` (full uninstall + reinstall) for all version upgrades, so the standard upgrade path is unaffected. The `OR REINSTALL` clause covers power users running `msiexec /fa` directly. ## PR Checklist - [x] **Communication:** Discussed approach via PRs #46866, #47177, #46745 - [ ] **Tests:** Installer infrastructure only — no runtime behaviour changes - [ ] **Localization:** N/A - [ ] **Dev docs:** N/A - [ ] **New binaries:** N/A ## Detailed Description of the Pull Request / Additional comments Based on the approach from PR #46745 by @yeelam-gordon, rebased onto latest main and switched from hard-links to file copies after the DACL contamination root cause was identified. Hardening (UTF-8 read, path containment, catastrophic-case escalation, REINSTALL repair, BaseApplications-filtered dedup) added in response to review feedback. These changes are purely build/installer infrastructure — no runtime behaviour changes to any PowerToys module. ## Validation Steps Performed Validated on a 0.99.4 / 0.99.5 local install (per-user `%LocalAppData%\PowerToys`): - ✅ `dumpbin /dependents` across the installed PowerToys tree confirmed zero binaries import `mfc140*`, `mfcm140*`, `vcamp140*`, or `vcomp140*` — the cleanup target removes ~11 MB of genuinely unused VC runtime DLLs. - ✅ `System.Data.SqlClient` has zero call-sites in PowerToys source. - ✅ Local installer build produces a 296 MB MSI (down from 393 MB pre-dedup, ~97 MB cab savings purely from the build-time WiX dedup). - ✅ MSI table inspection (`wix msi decompile`) confirms the deferred CAs are present (`CreateWinAppSDKHardlinks`, `DeleteWinAppSDKHardlinks`) and the `hardlinks.txt` File row is registered. - ✅ MSI table inspection confirms .NET runtime DLLs (`hostfxr.dll`, `coreclr.dll`, `hostpolicy.dll`, `clretwrc.dll`, `Accessibility.dll`, `backup_restore_settings.json`) appear ONLY in `BaseApplicationsFiles_File_*`, NOT in `WinUI3ApplicationsFiles_File_*` — proving the build-time dedup worked. - ✅ Post-install verification: deduplicated files materialised at both root and WinUI3Apps with byte-identical SHA256 hashes, and `fsutil hardlink list` returns link-count == 1 for each — proving the install-time copy approach worked, not hard-link. - ✅ DACL on root .NET runtime DLLs is clean: no Package SID, no Capability SID, no SYSAPPID conditional ACE, no `ALL APPLICATION PACKAGES` ACE — Monaco preview load path is safe. - ✅ DACL on WinUI3Apps copies has the rich MSIX inheritance — context-menu shells continue to work (matches 0.99.1). - ✅ All four MSIX sparse packages (PowerRename, ImageResizer, FileLocksmith, NewPlus) registered after install. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
41 lines
1.1 KiB
Modula-2
41 lines
1.1 KiB
Modula-2
LIBRARY "PowerToysSetupCustomActionsVNext"
|
|
|
|
EXPORTS
|
|
LaunchPowerToysCA
|
|
CheckGPOCA
|
|
CleanVideoConferenceRegistryCA
|
|
ApplyModulesRegistryChangeSetsCA
|
|
DetectPrevInstallPathCA
|
|
RemoveScheduledTasksCA
|
|
RestoreBuiltInNewContextMenuCA
|
|
TelemetryLogInstallSuccessCA
|
|
TelemetryLogInstallCancelCA
|
|
TelemetryLogInstallFailCA
|
|
TelemetryLogUninstallSuccessCA
|
|
TelemetryLogUninstallCancelCA
|
|
TelemetryLogUninstallFailCA
|
|
TelemetryLogRepairCancelCA
|
|
TelemetryLogRepairFailCA
|
|
TerminateProcessesCA
|
|
InstallEmbeddedMSIXCA
|
|
InstallDSCModuleCA
|
|
InstallCmdPalPackageCA
|
|
UnApplyModulesRegistryChangeSetsCA
|
|
UnRegisterCmdPalPackageCA
|
|
UnRegisterContextMenuPackagesCA
|
|
UninstallEmbeddedMSIXCA
|
|
UninstallDSCModuleCA
|
|
UninstallServicesCA
|
|
UninstallCommandNotFoundModuleCA
|
|
UpgradeCommandNotFoundModuleCA
|
|
UnsetAdvancedPasteAPIKeyCA
|
|
CleanImageResizerRuntimeRegistryCA
|
|
CleanFileLocksmithRuntimeRegistryCA
|
|
CleanPowerRenameRuntimeRegistryCA
|
|
CleanNewPlusRuntimeRegistryCA
|
|
SetBundleInstallLocationCA
|
|
InstallPackageIdentityMSIXCA
|
|
UninstallPackageIdentityMSIXCA
|
|
CreateWinAppSDKHardlinksCA
|
|
DeleteWinAppSDKHardlinksCA
|