Skip to content

Fix PowerShell modules always updating in CurrentUser scope - #5169

Merged
Gabriel Dufresne (GabrielDuf) merged 2 commits into
mainfrom
fix/5163-powershell-update-scope
Jul 22, 2026
Merged

Fix PowerShell modules always updating in CurrentUser scope#5169
Gabriel Dufresne (GabrielDuf) merged 2 commits into
mainfrom
fix/5163-powershell-update-scope

Conversation

@GabrielDuf

@GabrielDuf Gabriel Dufresne (GabrielDuf) commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

This pull request improves how NuGet-based package managers handle update detection and scope assignment, specifically addressing issues where PowerShell modules installed for "AllUsers" were not being updated correctly. The changes ensure that updates inherit the correct installation scope, preventing regressions where updates defaulted to the wrong user context. The update logic is now more robust and thoroughly tested.

Key improvements and fixes:

Update Detection and Scope Handling:

  • Refactored the update detection logic in BaseNuGet.cs to parse update responses using a new ParseUpdatesResponse method, which ensures each update package carries the correct installed scope. This prevents updates from incorrectly defaulting to "CurrentUser" when the package was installed for "AllUsers".
  • Introduced the BuildInstalledScopeMap utility to map installed package IDs to their scopes, mirroring the version selection logic so that both version and scope are consistently determined.

Testing and Regression Coverage:

  • Added comprehensive unit tests in PowerShell7ManagerTests.cs to verify that update packages inherit the correct scope, including scenarios for "AllUsers", "CurrentUser", and packages installed in both scopes. These tests specifically guard against regressions.
  • Updated test imports to include the new utilities and ensure test coverage for the refactored logic.

Code Maintenance:

  • Added missing namespace imports in BaseNuGet.cs for consistency and to support the new logic.

PowerShell 7 modules installed under AllUsers were always updated with
`Update-PSResource -Scope CurrentUser`, installing a fresh CurrentUser
copy and leaving the AllUsers version stale, so the update was detected
again on every scan.

The scope-detection and operation-helper logic were both correct, but
`BaseNuGet.GetAvailableUpdates_UnSafe` built the update packages fresh
from the GetUpdates() response without carrying the installed package's
scope. The operation helper therefore fell back to CurrentUser.

Carry the installed scope onto the update package (as Scoop already
does). When a module is installed in both scopes, prefer the system-wide
(AllUsers/Machine) copy so it never stays stale. Only PowerShell 7 is
affected (`Update-PSResource` takes `-Scope`); PowerShell 5.x
`Update-Module` has no `-Scope` and updates in place.

Extract the scope-map building and update-response parsing into testable
statics (`BuildInstalledScopeMap`, `ParseUpdatesResponse`) and add
regression tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Preserves PowerShell module update scope when parsing NuGet update responses.

Changes:

  • Maps installed package IDs to scopes, preferring Machine.
  • Applies detected scopes to update packages.
  • Adds PowerShell 7 regression tests.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
BaseNuGet.cs Adds scope mapping and scoped update parsing.
PowerShell7ManagerTests.cs Tests Machine and CurrentUser update scopes.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/UniGetUI.PackageEngine.Managers.Generic.NuGet/BaseNuGet.cs Outdated
Copilot correctly noted the prefer-Machine heuristic paired a Machine
scope with the last-enumerated (CurrentUser) version, and the max-version
filter drops such entries anyway, so it did not actually fix the
dual-scope case it implied.

Make the scope map last-wins, matching the version map, so scope and
installed version always come from the same enumerated package. A
single-scope module (the reported #5163 case) still updates in its own
scope. True per-scope updates for dual-scope installs would require
scope-aware package identity, which the scope-blind upgrade loader does
not support; that is a separate follow-up.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

@GabrielDuf
Gabriel Dufresne (GabrielDuf) merged commit c0ddaa6 into main Jul 22, 2026
6 checks passed
@GabrielDuf
Gabriel Dufresne (GabrielDuf) deleted the fix/5163-powershell-update-scope branch July 22, 2026 12:45
@GabrielDuf Gabriel Dufresne (GabrielDuf) linked an issue Jul 22, 2026 that may be closed by this pull request
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Powershell modules always updates as User Scope

3 participants