Microsoft.WinGet.Client throws System.InvalidOperationException: Attempt to update previously set global instance #3253
Conversation
This file contains 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
JohnMcPMS
reviewed
May 16, 2023
src/PowerShell/Microsoft.WinGet.Client.Cmdlets/Acl/WinGetAssemblyLoadContext.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Cmdlets/Acl/WinGetAssemblyLoadContext.cs
Outdated
Show resolved
Hide resolved
JohnMcPMS
approved these changes
May 16, 2023
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
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.
Microsoft.WinGet.Client throws
System.InvalidOperationException:“Attempt to update previously set global instance.”when used in winget configure with a resource from Microsoft.WinGet.DSCThis is because the custom AssemblyLoadContext implemented by the client module loads WinRT.Runtime.dll into the same processes where the configuration server already have WinRT.Runtime.dll loaded. When there are multiple versions of WinRT.Runtime.dll loaded in process this exception gets thrown. More info
The fix is to always load WinRT.Runtime.dll into the default assembly context, if its not loaded by the time our handler is executed and always return null in the Load implementation of the custom ALC.
This is a problem any PowerShell module that uses cswinrt will have (if there's another one out there)
Microsoft Reviewers: Open in CodeFlow