runtime: Regression in .NET 8.0-preview.5: dependent assembly is not included in TPA list when running fxdependent pwsh build with preview.5 dotnet.exe
Description
This is root cause of the PowerShell issue Microsoft.Management.Infrastructure can’t be loaded in latest .NET 8 Preview 5 build.
My investigation shows it’s a regression in .NET 8-preview.5.
The Microsoft.Management.Infrastructure.dll (MMI.dll) can be loaded in preview.5 without a problem by Assembly.LoadFrom. However, when running a fxdependent build of pwsh with the .NET 8.0-preview.5 SDK (through ....\dotnet.exe ....\pwsh.dll), the MMI.dll doesn’t get included in the Trusted_Platform_Assemblies (TPA) list, and thus it cannot be found when the loading is requested. As a comparison, when running the same fxdependent build of pwsh with the .NET 8-preview.4 SDK, the MMI.dll is included in the TPA list and hence the loading works as expected at pwsh startup.
The startup tracing logs for using the preview.5 (p5-trace.txt) and preview.4 (p4-trace.txt) SDKs are attached. The traces were generated by setting COREHOST_TRACE = 1. The build produced pwsh.deps.json file for the fxdependent build is also attached for your reference.
I want to call out that the Microsoft.Management.Infrastructure NuGet package ships netstandard1.6 managed assemblies (MMI.dll). Maybe the regression in .NET 8 preview.5 is related to the netstandard1.6 TFM? Just a guess.
p5-trace.txt p4-trace.txt pwsh.deps.json.txt
The .NET 8.0-preview.5 build I’m using is 8.0.100-preview.5.23269.4.
Reproduction Steps
See the repro steps in https://github.com/PowerShell/PowerShell/issues/19679. Also, the tracing logs should provide lots of information about the issue.
Expected behavior
The fxdependent pwsh build works as expected when using with the .NET 8.0-preview.5 build.
Actual behavior
Crash at startup because the MMI.dll cannot be found – it’s not included in the TPA list.
Regression?
Yes. it’s a regression from .NET 8.0-preview.4.
Known Workarounds
N/A
Configuration
PS:13> ..\dotnet8-p5\dotnet.exe --version
8.0.100-preview.5.23269.4
Win10-x64 platform
Other information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 26 (25 by maintainers)
We can, for the PowerShell packages. @adityapatwardhan is working on the next preview release, so he can share more about the plan.
However, for any application out there that host PowerShell by using the PowerShell NuGet packages (e.g. System.Management.Automation), they will need to explicitly add this runtime config too, otherwise, they will run into the same problem.
Yes, we should be able to use the config to unblock shipping the Docker images.
It looks like @elinor-fung has offered a long-term plan to resolve this.
But in the short term, we need to figure out what to do so we can ship the Preview 5 Docker images.
@elinor-fung, is the use of this config property something that should be acceptable for shipping PowerShell in this configuration to customers in this Preview release?
@daxian-dbw, are we able to get a new release of PowerShell in time for the .NET 8 Preview 5 release (June 13)? If not, would it be acceptable for us to modify the
C:\Program Files\powershell\.store\powershell.windows.x64\7.4.0-preview.3\powershell.windows.x64\7.4.0-preview.3\tools\net8.0\any\pwsh.runtimeconfig.jsonfile as part of our installation logic in our Dockerfile so that it includes this property?