| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
This PR has 17 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience! Quantification details
Label : Extra Small Size : +11 -6 Percentile : 6.8% Total files changed: 2 Change summary by file extension: .cs : +4 -2 .ps1 : +7 -4 Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
Sorry, something went wrong.
|
I'm not sure if we want to make this breaking change, given that it has been the way it works since PowerShell 6. |
Sorry, something went wrong.
|
I think it's better to keep the current behavior unchanged. For modules built against netstandard2.0 or net462, we can have a AssemblyLoadContextProxy type that wraps some simple reflection APIs to create a custom ALC and load an assembly by path to that ALC. See the following as an example: |
Sorry, something went wrong.
|
It seems general question is - should Engine use only default ALC for PowerShell's type resolution? Maybe it makes sense to make this configurable? |
Sorry, something went wrong.
It definitely needs to resolve types from assemblies loaded by Assembly.Load(byte[]). Many users depend on it. Even though there is no report on Assembly.LoadFile when the regression was introduced by #11088, types from assemblies loaded by Assembly.LoadFile can be resolved by PowerShell in all prior versions of PowerShell Core (and I think it's the same to Windows PowerShell, but didn't verify). I don't think it's a breaking change that we can accept, and hence close this PR. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
For modules that target both Windows PowerShell and PowerShell Core, they are usually built against either netstandard2.0, or net462, so that one single set of assemblies can work on both .NET Framework and .NET Core.
For those modules, the API Assembly.LoadFile is usually used to load a dependency assembly into a separate load context when working in PowerShell Core to isolate the dependency, so as to avoid assembly loading conflicts with other modules. This usually happens when the dependency is commonly used by modules, such as Newtonsoft.Json and YamlDotNet.
Today, assemblies loaded by Assembly.LoadFile are discoverable by PowerShell's type resolution, and this breaks the isolation those modules are looking for when using Assembly.LoadFile. Since they are built against netstandard2.0 and net462, they cannot use the AssemblyLoadContext APIs for creating a custom load context but have to depend on Assembly.LoadFile which loads an assembly in a separate assembly load context.
This PR is a breaking change.
PR Context
Assemblies loaded by Assembly.LoadFile are made discoverable by #12203.
However, the original issues that PR was to address is just for assemblies loaded from memory by Assembly.Load(byte[]), and Assembly.LoadFile was never the ask.
PR Checklist