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
Describe the bug
Our winget PowerShell modules have their own custom AssemblyLoadContext to load binaries to avoid dependency conflicts. This is the recommended solution from the PowerShell team.
However, loading WinRT.Runtime.dll into different custom ALCs result in System.InvalidOperationException:“Attempt to update previously set global instance.”. Forcing me to special case it and load it in the default context.
This works ok if all the PowerShell modules uses the same WinRT.Runtime.dll version but there are other modules that can use a different version, like BurnToast that uses 1.1.0.0, which can't be loaded in the same session.
This was apparently fixed some time ago but it came back based on #623
To Reproduce
Load same version of WinRT.Runtime.dll into the default context and a custom ALC.
Expected behavior
WinRT.Runtime.dll should load in both contexts.
The text was updated successfully, but these errors were encountered:
Moving to CsWinRT 2.1+ can affect your ALC setup as #1390 moved the component loading into WinRT.Runtime.dll from the projection binary. Our solution has been to continue to load WinRT.Runtime.dll into the default context, but this means that the unmanaged load now happens in the default context rather than our custom context. This can lead to a Class not registered error due to not finding the component binary.
The simple solution is to add a ResolvingUnmanagedDll event handler to the default context. We had previously had no need as all of our unmanaged binaries were being loaded from managed ones already loaded into our custom context.
Describe the bug
Our winget PowerShell modules have their own custom AssemblyLoadContext to load binaries to avoid dependency conflicts. This is the recommended solution from the PowerShell team.
However, loading WinRT.Runtime.dll into different custom ALCs result in
System.InvalidOperationException:“Attempt to update previously set global instance.”
. Forcing me to special case it and load it in the default context.This works ok if all the PowerShell modules uses the same WinRT.Runtime.dll version but there are other modules that can use a different version, like BurnToast that uses 1.1.0.0, which can't be loaded in the same session.
This was apparently fixed some time ago but it came back based on #623
To Reproduce
Load same version of WinRT.Runtime.dll into the default context and a custom ALC.
Expected behavior
WinRT.Runtime.dll should load in both contexts.
The text was updated successfully, but these errors were encountered: