Remove or neuter Microsoft.DotNet.PlatformAbstractions

[danmoseley]

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.

[danmoseley]

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 dotnet/core-setup#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.