Refactor PowerShell Core to use the default CoreCLR loader instead #3903
Conversation
| @@ -31,11 +31,7 @@ internal partial class PowerShellAssemblyLoadContext : AssemblyLoadContext | |||
| // When the first attempt fails, we again need to retrieve the resource string to construct another exception, which ends up with an infinite loop. | |||
| private const string BaseFolderDoesNotExist = "The base directory '{0}' does not exist."; | |||
| private const string ManifestDefinitionDoesNotMatch = "Could not load file or assembly '{0}' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference."; | |||
| private const string AssemblyPathDoesNotExist = "Could not load file or assembly '{0}' or one of its dependencies. The system cannot find the file specified."; | |||
| private const string InvalidAssemblyExtensionName = "Could not load file or assembly '{0}' or one of its dependencies. The file specified is not a DLL file."; | |||
| private const string AbsolutePathRequired = "Absolute path information is required."; | |||
| private const string SingletonAlreadyInitialized = "The singleton of PowerShellAssemblyLoadContext has already been initialized."; | |||
There was a problem hiding this comment.
What is the localization story for these messages?
There was a problem hiding this comment.
Sorry for the late response. These strings are currently not localized because the loading of a satellite resource DLL when a loading exception happens causes a recursion. It's explained in the comment above the first resource string. Eventually, after moving the remaining code from PowerShellAssemblyLoadContext.dll to SMA.dll, we can reconsider the localization.
|
Minor update to add back Since the I have verified that PackageManagement works with this update. |
Partially fix #3649
Issue Summary
The API
AppDomain.GetAssembliesis brought back in .NET Core 2.0 which returns the loaded assemblies from the default loader. Therefore it's possible now for powershell to just depend on the default CoreCLR loader without having our own assembly load context getting in the picture. This would greatly simplify the scenario of hosting powershell in applications.Fix
Remove the code that spins up our own assembly load context. Keep the code that registers our
Resolvemethod to the default loader'sResolvingevent, so that we can continue to do special assembly resolution as needed (such as the GAC probing logic needed for consuming FullCLR PS modules).Essentially, the assembly
Microsoft.PowerShell.CoreCLR.AssemblyLoadContext.dllis not needed anymore, the remaining code should be moved to S.M.A.dll. However, that will break DSC and other native hosts that are hosting powershell. So this assembly is kept for now.CoreFX Fixes needed
https://github.com/dotnet/corefx/issues/18989
https://github.com/dotnet/corefx/issues/18877
https://github.com/dotnet/corefx/issues/18791
This PR is not blocked by those CoreFX issues, but it's incomplete until we have the fixes. Those issues have already been addressed, and #3887 will get those fixes for us.
Note that this PR is NOT blocked by #3887.
Follow-up work
This PR addresses the first task listed in #3649. Three tasks are remaining.