Repository navigation
Find help again after the help cache is reset - #28294
Christian Pfeiffer (ChrisTX) wants to merge 1 commit into
Conversation
Sorry, something went wrong.
When Get-Help finds the help of a cmdlet or function in a file, it sets the HelpFile property of the command to the full path of that file, and a full path in HelpFile is loaded directly from then on. Reset(), which runs after Update-Help and when the UI culture changes, cleared the cached help but kept those paths, so the session kept getting the help from the same file: the help Update-Help installed in the CurrentUser scope wasn't found when help in $PSHOME had been loaded before, and the help stayed in the previous UI culture. CommandHelpProvider now keeps the original HelpFile of the commands it changes, and Reset() restores them. Fixes PowerShell#28274 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Sorry, something went wrong.
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are recorded for the changes to help rediscovery after cache resets.
No open issues 🎉
What changed in this PRFixes #28274 by making Get-Help search for help again after a cache reset, rather than reuse a previously resolved file path after Update-Help or a UI culture change.
Changes:
- Tracks original command help paths with weak references and restores them on reset.
- Adds a regression test that verifies help switches from en-US to de-DE when the UI culture changes.
| File | Description |
|---|---|
| test/powershell/engine/Help/HelpSystem.Tests.ps1 | Tests help rediscovery after a UI culture change. |
| src/System.Management.Automation/help/CommandHelpProvider.cs | Saves original help paths and restores them when clearing the help cache. |
Review effort: Balanced
Sorry, something went wrong.
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
Sorry, something went wrong.
Reviewers
At least 1 approving review is required to merge this pull request.
PR Summary
Fixes #28274.
When Get-Help finds the help of a cmdlet or function in a file, CommandHelpProvider sets the HelpFile property of the command to the full path of that file. From then on, FindHelpFile()/GetHelpFile() load that path directly instead of searching for the help.
Reset() runs after Update-Help and when the UI culture changes. It clears the cached help, but leaves those full paths in place, so the session keeps loading the help from the same file:
This PR makes CommandHelpProvider keep the original HelpFile value of every command it changes, and Reset() restores those values, so the help is searched for again. The original values are kept in a ConditionalWeakTable, so commands of removed modules aren't kept alive until the next reset. HelpFile still shows the full path of the help file after Get-Help, as before.
The new test in HelpSystem.Tests.ps1 covers the UI culture case, as it doesn't need help in $PSHOME: a script module with help in en-US and de-DE, Get-Help in en-US, then in de-DE. Without the fix, the second Get-Help returns the en-US help.
PR Context
Get-Help in a session returns outdated help after Update-Help or a change of the UI culture, until a new session is started. This also makes HelpSystem.Tests.ps1 fail when $PSHOME contains help: "Validate that get-help works for CurrentUserScope" installs the test help in the CurrentUser scope, but gets the help from $PSHOME that an earlier test loaded.
I built and tested the change on 7.6.9 (HelpSystem.Tests.ps1 passes, including with help in $PSHOME, and the new test fails without the fix). It applies cleanly to master, but I don't have the .NET 11 SDK master needs here, so the build on master is left to CI.
PR Checklist
🤖 Generated with Claude Code