-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Make Repair-WGPM a COM-aware cmdlet and rework version retrieval #5842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
Member
…hat it shouldn't actually use COM to get the version (nor need to get the version *3* times when changing versions)
Trenly
reviewed
Oct 29, 2025
| public static WinGetCLICommandResult RunWinGetVersionFromCLI(PowerShellCmdlet pwshCmdlet, bool fullPath = true) | ||
| { | ||
| var wingetCliWrapper = new WingetCLIWrapper(fullPath); | ||
| return wingetCliWrapper.RunCommand(pwshCmdlet, "--version"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
florelis
approved these changes
Oct 31, 2025
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
JohnMcPMS
added a commit
to JohnMcPMS/winget-cli
that referenced
this pull request
Nov 4, 2025
…rosoft#5842) Fixes microsoft#5826 and microsoft#5827 ## Issue A previous change introduced a COM API to retrieve the WinGet version. The PowerShell methods to get the version were updated to try using it before invoking the existing method (run `winget --version`). This caused Repair-WGPM to use COM for the first time (IFF a version specifier was provided [which includes `-Latest`]). This caused the two linked issues: 1. microsoft#5826 :: In .NET Framework (Windows PowerShell), the .winmd file must be found in order to generate the COM type information at runtime. This is required when jit'ing the new version API, used only when a version specifier is provided. This doesn't affect .NET Core (PowerShell 7) because exceptions are swallowed to support backward compat and the types are all pre-generated by CsWinRT. Only commands deriving from a specific type were doing the initialization required. 2. microsoft#5827 :: Calling a COM API means that the server is active, making attempts to install the package fail due to an in-use error. This required `-Force` to be provided, again only if a version specifier was provided. ## Change The larger part of this change reworks the existing assert and repair state machine to better re-use the call to `winget --version` that is actually attempting to probe for WinGet CLI functionality. We keep that result around and use it when comparing to the supplied target version rather than attempting to retrieve the version again. If the version is not correct, we attach it to the exception that is thrown so that we can re-use it once again during the attempt to install the different version. Since the first attempt to call `winget --version` has to succeed in order to get to the code that would check the current version, we can successfully avoid the COM call in this path every time. Ultimately this means that if WinGet is already installed properly, attempting to change the version with Repair only gets the version once instead of the previous 3 times. The final portion of the change updates the base command for Repair and Assert to the one that provides the COM initialization. While this shouldn't be necessary with the other portion, it is preferable to supply `-Force` as a workaround than to simply wait for a resolution if the type cannot be loaded.
JohnMcPMS
added a commit
that referenced
this pull request
Nov 4, 2025
…to 1.12) (#5858) CP of #5842 ## Issue A previous change introduced a COM API to retrieve the WinGet version. The PowerShell methods to get the version were updated to try using it before invoking the existing method (run `winget --version`). This caused Repair-WGPM to use COM for the first time (IFF a version specifier was provided [which includes `-Latest`]). This caused the two linked issues: 1. #5826 :: In .NET Framework (Windows PowerShell), the .winmd file must be found in order to generate the COM type information at runtime. This is required when jit'ing the new version API, used only when a version specifier is provided. This doesn't affect .NET Core (PowerShell 7) because exceptions are swallowed to support backward compat and the types are all pre-generated by CsWinRT. Only commands deriving from a specific type were doing the initialization required. 2. #5827 :: Calling a COM API means that the server is active, making attempts to install the package fail due to an in-use error. This required `-Force` to be provided, again only if a version specifier was provided. ## Change The larger part of this change reworks the existing assert and repair state machine to better re-use the call to `winget --version` that is actually attempting to probe for WinGet CLI functionality. We keep that result around and use it when comparing to the supplied target version rather than attempting to retrieve the version again. If the version is not correct, we attach it to the exception that is thrown so that we can re-use it once again during the attempt to install the different version. Since the first attempt to call `winget --version` has to succeed in order to get to the code that would check the current version, we can successfully avoid the COM call in this path every time. Ultimately this means that if WinGet is already installed properly, attempting to change the version with Repair only gets the version once instead of the previous 3 times. The final portion of the change updates the base command for Repair and Assert to the one that provides the COM initialization. While this shouldn't be necessary with the other portion, it is preferable to supply `-Force` as a workaround than to simply wait for a resolution if the type cannot be loaded.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #5826 and #5827
Issue
A previous change introduced a COM API to retrieve the WinGet version. The PowerShell methods to get the version were updated to try using it before invoking the existing method (run
winget --version).This caused Repair-WGPM to use COM for the first time (IFF a version specifier was provided [which includes
-Latest]). This caused the two linked issues:-Forceto be provided, again only if a version specifier was provided.Change
The larger part of this change reworks the existing assert and repair state machine to better re-use the call to
winget --versionthat is actually attempting to probe for WinGet CLI functionality. We keep that result around and use it when comparing to the supplied target version rather than attempting to retrieve the version again. If the version is not correct, we attach it to the exception that is thrown so that we can re-use it once again during the attempt to install the different version.Since the first attempt to call
winget --versionhas to succeed in order to get to the code that would check the current version, we can successfully avoid the COM call in this path every time. Ultimately this means that if WinGet is already installed properly, attempting to change the version with Repair only gets the version once instead of the previous 3 times.The final portion of the change updates the base command for Repair and Assert to the one that provides the COM initialization. While this shouldn't be necessary with the other portion, it is preferable to supply
-Forceas a workaround than to simply wait for a resolution if the type cannot be loaded.Validation
Manually confirmed flow of saved version information with debugger and the lack of COM server running.
Additional tests are planned for the internal build to better test the real flow due to the complexity.
Microsoft Reviewers: Open in CodeFlow