You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Honor the configured WinGet scope and architecture in package details - #5521
Package details and "Download installer" now pick the same WinGet installer that install and update use, honoring the configured scope and architecture.
The bug
With WinGet set to Machine | Global scope, updating Visual Studio Code correctly ran VSCodeSetup-x64. But the details "Installer URL" and every "Download installer" entry point (details page, right-click, toolbar) returned VSCodeUserSetup-x64.
Cause: install and update pass --scope and --architecture from the applicable install options. Package details queried Pinget with neither, so Pinget took the first installer for the system architecture. VS Code's manifest lists the user installer before the machine one.
Why every download path was affected: the details field and all download paths read Details.InstallerUrl.
Changes
One rule for scope and architecture: a package override wins, then the install options. Both are dropped after an "update not applicable" retry. The rule is now WinGetPkgOperationHelper.GetEffectiveScope / GetEffectiveArchitecture, shared by the operation command line and package details, so they can't drift again.
In-process details (COM / Pinget helpers): query Pinget with both values. The query runs again without them only when they actually excluded an installer, mirroring the native GetApplicableInstaller fallback.
Bundled Pinget CLI details (system winget CLI mode): this used to take Installers[0] outright, because the Rust show --output json returns the raw manifest without a selected installer. It now follows Pinget's selection rules:
an installer without a Scope matches any scope
architecture is filtered and ranked by system preference
a preference that matches nothing falls back to the unconstrained pick
Users with nothing configured now get the installer that matches their machine instead of the first one listed.
Verification
New unit tests cover the scoped query, the retry and no-retry cases, the CLI selection by scope and architecture, installers without a scope, and the fallback.
Ran the real in-process provider against the live winget index for Microsoft.VisualStudioCode (temporary test, not committed):
no scope → VSCodeUserSetup (reproduces the bug)
machine → VSCodeSetup
machine + x64 → VSCodeSetup-x64
user + x86 → no x86 installer, so it falls back to the unconstrained pick
Full UniGetUI.PackageEngine.Tests suite passes. dotnet format whitespace and dotnet format style are clean.
Not checked in the running app on an x64 machine. The test box is ARM64, where the live run returned arm64 URLs.
Install and update pass --scope and --architecture from the applicable
install options, but package details queried Pinget with neither. Pinget
then picked the first installer applicable to the system architecture,
and many manifests list the user installer before the machine one
(Microsoft.VisualStudioCode: VSCodeUserSetup before VSCodeSetup). The
details "Installer URL" field and every "Download installer" entry point
read Details.InstallerUrl, so a user configured for Machine scope saw and
downloaded the per-user installer while updates correctly used the
machine one.
The effective scope/architecture rule (package override, then options,
dropped after an "update not applicable" retry) is hoisted into
WinGetPkgOperationHelper so the operation command line and package
details cannot drift again. Details now query Pinget with both values,
and retry without them only when they actually excluded an installer,
mirroring the native GetApplicableInstaller fallback.
The bundled Pinget CLI provider (system winget CLI mode) used to take
Installers[0] outright, since the Rust show --output json emits the raw
manifest without a selected installer. It now mirrors Pinget's
selection: an installer without a Scope matches any scope, architecture
is filtered and ranked by system preference, and an unsatisfiable
preference falls back to the unconstrained pick.
Fixes#5519
Installer selection now depends on mutable install options, but the details view reuses populated metadata. PackageDetailsViewModel.LoadDetailsAsync skips loading when IsPopulated is true (lines 244–246), and PackageDetailsWindow.SaveInstallOptionsAsync only saves the options (lines 160–165). Open details with user scope, save a machine-scope package override, then reopen the same package: the displayed URL remains the user installer. Installation uses the new preference, and downloads reload details, so they can disagree with the displayed URL. Refresh or invalidate installer metadata when the effective scope or architecture changes, and add a regression test for this sequence.
The existing XML summary now describes ApplyOperationOverrides as checking elevation, but this hook only overrides the architecture for updates. Move the elevation summary back to ApplyElevationRequirements and document the architecture override here so callers see the correct behavior.
Restore shared loading coordination and complete npm, operation-test, launcher, and platform integration. Keep Cargo metadata acquisition cancellable when FileStream encounters a sharing lock before the native lock call, and close HTTP fixtures without a shutdown race.
Upstream-Commit: 6ef60b4
Upstream-PR: Devolutions#5070
Upstream-Commit: c87bd6b
Upstream-PR: Devolutions#5039
Upstream-Commit: 566ea0c
Upstream-PR: Devolutions#5346
Upstream-Commit: 4f8a820
Upstream-PR: Devolutions#5348
Upstream-Commit: 8220a4b
Upstream-PR: Devolutions#5402
Upstream-Commit: 288ef55
Upstream-PR: Devolutions#5521
Upstream-Commit: 83efec6
Upstream-PR: Devolutions#5569
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
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.
![randy-but-a-ro[bot]](https://avatars.githubusercontent.com/in/113084?s=60&v=4){kind=small}
Package details and "Download installer" now pick the same WinGet installer that install and update use, honoring the configured scope and architecture.
The bug
With WinGet set to Machine | Global scope, updating Visual Studio Code correctly ran
VSCodeSetup-x64. But the details "Installer URL" and every "Download installer" entry point (details page, right-click, toolbar) returnedVSCodeUserSetup-x64.--scopeand--architecturefrom the applicable install options. Package details queried Pinget with neither, so Pinget took the first installer for the system architecture. VS Code's manifest lists the user installer before the machine one.Details.InstallerUrl.Changes
One rule for scope and architecture: a package override wins, then the install options. Both are dropped after an "update not applicable" retry. The rule is now
WinGetPkgOperationHelper.GetEffectiveScope/GetEffectiveArchitecture, shared by the operation command line and package details, so they can't drift again.In-process details (COM / Pinget helpers): query Pinget with both values. The query runs again without them only when they actually excluded an installer, mirroring the native
GetApplicableInstallerfallback.Bundled Pinget CLI details (system winget CLI mode): this used to take
Installers[0]outright, because the Rustshow --output jsonreturns the raw manifest without a selected installer. It now follows Pinget's selection rules:Scopematches any scopeUsers with nothing configured now get the installer that matches their machine instead of the first one listed.
Verification
Microsoft.VisualStudioCode(temporary test, not committed):VSCodeUserSetup(reproduces the bug)machine→VSCodeSetupmachine+x64→VSCodeSetup-x64user+x86→ no x86 installer, so it falls back to the unconstrained pickUniGetUI.PackageEngine.Testssuite passes.dotnet format whitespaceanddotnet format styleare clean.Not checked in the running app on an x64 machine. The test box is ARM64, where the live run returned arm64 URLs.
Closes #5519