Updating with the latest .NET Core preview packages causes some regressions:

Latest System.Runtime.Loader.AssemblyLoadContext causes a regression in PSAssemblyLoadContext. The regression has been fixed on PS side.
With .NET Core 1.0.0 RTM, dotnet.exe doesn't verify the existence of assemblies that are built from the local projects when check the TPA deps assemblies, and thus we are able to remove IL assemblies after crossgen. However, the latest dotnet.exe checks the existence of locally built assemblies, so IL assemblies cannot be removed anymore.
The new dotnet.exe loads IL assemblies in precedence, instead of NI assemblies. The symptom is that you will find PowerShellAssemblyLoadContext.dll is loaded by the default load context when both the IL and NI assemblies exist. But with RTM packages, PowerShellAssemblyLoadContext.ni.dll gets loaded by the default load context under the same circumstance. This doesn't affect us too much now because PowerShellAssemblyLoadContext handles the loading of other PS assemblies and it prefers NI over IL assemblies. However, when the legacy APIs are back and it's time to retire PSALC, our crossgen story will be broken if the default context prefer IL over NI. I will start a conversation with .NET Core team on this.
Latest Microsoft.Win32.Registry will now raise PlatformNotSupportedException when you call any static members of it on UNIX. In PS code, we call some of its static properties when initializing some types (e.g. System.Management.Automation.Utils), and that caused PS to crash in UNIX. This is fixed.
When working on #4, I found both Registry and Certificate providers are shown up in UNIX PS. They don't work in UNIX at all, and should not be exposed (until we have a UNIX implementation of Certificate provider someday). They are now excluded from compilation for UNIX PS.
[System.Text.Encoding]::Default is available via reflection at runtime (exposed by System.Private.CoreLib), but it's not exposed in the reference contract of System.Text.Encoding, and thus we cannot use it in PS Code. This mismatch causes a redirection test to fail. The test is fixed to skip Encoding.Default for now. I will check with .NET Core team to clarify this mismatch.
The exclusion of 'Certificate' provider causes some failures on UNIX PS, because some tests are using Cert:\ to test the error behavior when not using a FileSystemProvider drive. The tests are fixed.

Update CoreCLR to the latest packages #2343

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions