Runtime: Remove or neuter Microsoft.DotNet.PlatformAbstractions

[danmosemsft]

As agreed more broadly (with @dleeapho et al) we are committed to remove (in some sense) Microsoft.DotNet.PlatformAbstractions from core-setup in 3.0.

After https://github.com/dotnet/corefx/issues/31002 is completed, all its functionality will have equivalents in CoreFX proper - albeit in different shapes.

(Note that Microsoft.DotNet.DependencyModel is not included here - it must run on older runtimes, so it remains in core-setup.)

Options for M.DN.PA:

1. Remove it, and document alternative functionality. Because the existing package remains on NuGet, we avoid breaking existing code. (However it is possible it becomes out of date, eg., if we change how we determine the RID)
2. Retain it as is, but replace its implementation by calls into the CoreFX functionality, if semantically possible.
3. As above, but also move into CoreFX.

@eerhardt @dseefeld is the above correct? thoughts?

[dleeapho]

/cc @dagood

[dagood]

3 seems like the ideal plan.

We can also start with 1, then do 3 later if we end up needing to fix a breaking change. Waiting until a break adds uncertainty to future plans, though, so it seems safer to do it sooner.

[eerhardt]

I don't think we should retain PlatformAbstractions, unless we have a strong reason for it.

Here is my analysis of all the public functionality in this library. It can be boiled down to 3 public APIs that are necessary. Those 3 APIs are being proposed in https://github.com/dotnet/corefx/issues/31002. So if we get those 3 APIs in corefx, then I think we can delete this library completely.

The only issue I see with that plan is that PlatformAbstractions supports netstandard1.3 today. It will be a breaking/functionality loss to only support those 3 APIs on .NET Core 3.0 going forward. I believe it will be better for us to delete this library, but it may negatively impact our customers.

[danmosemsft]

I also prefer 1. Given that we will not innovate in it, preserving it seems like all cost and no value. We still have the option of servicing it if we have to.

If I understand right, deleting it need not block on the new API - any code already working will continue working. We can just delete it?

[eerhardt]

We can't just delete it.

I think we need replacement APIs first, especially for RuntimeEnvironment.GetRuntimeIdentifier(). What are we going to tell things like the CLI to use? The old 2.1 PlatformAbstractions?

We will also need Microsoft.Extensions.DependencyModel to stop using it.

We will also need to coordinate with the ASP.NET team. They are currently shipping this assembly in their shared framework. fyi - @natemcmaster

[natemcmaster]

The aspnet dependency on Microsoft.DotNet.PlatformAbstractions is transitive. I don't think anything in the aspnet directly references this assembly, so it might be possible to remove it. This would technically be a breaking change, but that might be okay since this is a new major version of aspnet.

[jkotas]

What are we going to tell things like the CLI to use?

CLI will upgrade to netcoreapp3.0 at some point, and then it can start using the new CoreFX API.

[eerhardt]

We will also need Microsoft.Extensions.DependencyModel to stop using it.

I've opened https://github.com/dotnet/core-setup/pull/5218 to do this.

I don't think anything in the aspnet directly references this assembly

I did a quick search and the biggest thing that jumped out to me:

https://github.com/aspnet/EntityFrameworkCore/blob/f38686a5974ab94463ccd68484e9133a13e7e13f/src/EFCore.Sqlite.Core/Infrastructure/SpatialiteLoader.cs#L110

[bricelam]

Without Microsoft.DotNet.PlatformAbstractions, how do I get the current RID?

[bricelam]

(Trying to remove EF's dependency, but can't see an alternative)

[eerhardt]

Without Microsoft.DotNet.PlatformAbstractions, how do I get the current RID?

The current proposal is to add an API to corefx for this. See https://github.com/dotnet/corefx/issues/31002. It would be helpful if you would list your scenario there, as there are questions as to why exposing an API that gets the current RID is necessary.

[eerhardt]

Moving this to Future as it is dependent on https://github.com/dotnet/corefx/issues/31002 which won't be completed in the 3.0 time frame.

[ViktorHofer]

I assume in cases where we build on .NET Framework, we still need to reference the PlatformAbstractions package to retrieve the RID? As an example, we need to retrieve the RID during the runtime build which can either run on Desktop or portable MSBuild.

[eerhardt]

For projects outside of the .NET product, they can continue using the older versions of PlatformAbstractions, if necessary.

However, projects inside of the .NET product should move off of PlatformAbstractions completely. Because once we stop building a new version of PlatformAbstractions, it won't be available in source-build.

For the runtime repo, when building on .NET Framework, I would either:

1. Check #if NETFRAMEWORK and return $"win-{RuntimeInformation.OSArchitecture.ToString().ToLowerInvariant()}".
2. At the beginning of the build, Exec out to a dotnet.exe process which writes the RID to a .props file

or portable MSBuild.

I don't know what this means. MSBuild is either running on .NET Framework or on .NET Core. If your task assembly is targeting netstandard, you can change it to target netcoreapp5.0 instead. That netstandard build is only going to work on .NET Core anyway, because you won't have the correct facades to run on .NET Framework with a netstandard library. (That's why all task assemblies that need to run on both, build for both.)

[ViktorHofer]

I don't know what this means.

"Portable msbuild" is just another name for msbuild targeting .NET Core.

[ViktorHofer]

Any suggestions for replacing RuntimeEnvironment.OperatingSystemVersion: https://github.com/dotnet/runtime/blob/7cbf0a7011813cb84c6c858ef19acb770daa777e/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs#L38?

[eerhardt]

Any suggestions for replacing RuntimeEnvironment.OperatingSystemVersion:

There are a couple ways of handling this. For the specific case you linked above, my opinion is that we should fix https://github.com/dotnet/runtime/issues/34977. Then this code can just use Environment.OSVersion.Version. IMO that is what customers actually want when they call this API.

The other place that RuntimeEnvironment is used in that file is just for Linux:

https://github.com/dotnet/runtime/blob/1db45ed953745c0e270d09df99828cb58772f4ad/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs#L207-L211

Since this method is only ever called on Linux, we could do 1 of the following approaches:

1. Read /etc/os-release in this code and parse out the OSName and OSVersion.
2. Parse the RuntimeInformation.RuntimeIdentifier into OSName and OSVersion.