Runtime: Packages that reference Microsoft.Bcl.AsyncInterfaces should have explicit target reference to netstandard2.1

[dozer75]

Describe the bug

While investigating recommended target frameworks for NuGet packages I discovered that the package Microsoft.Extensions.Hosting.Abstractions has a reference to Microsoft.Bcl.AsyncInterfaces in all versions above 3.1.0 for netstandard2.0 target framework. This causes projects that targets netstandard2.1 references this package incorrectly reference this.

To Reproduce

Steps to reproduce the behavior:

1. Using all versions newer than 3.1.0
2. Create a .NET Standard 2.1 project
3. Add a reference to Microsoft.Extensions.Hosting.Abstractions
4. The Microsoft.Bcl.AsyncInterfaces are referenced.

Expected behavior

If it is a fact that Microsoft.Extensions.Hosting.Abstractions needs async interfaces after 3.1.0, it must explicit add a target reference to netstandard2.1 where this package is excluded from reference.

The package Microsoft.Extensions.Hosting has target reference netstandard2.1 with the removal of this reference as the only difference, so it should be the same for Microsoft.Extensions.Hosting.Abstractions too.

I am not sure if this applies to other packages, but it is worth investigating which packages that should use netstandard2.1 and not.. It may be more something that should be investigated as a whole, not only for the extensions project.

[msftbot[bot]]

Tagging subscribers to this area: @safern, @viktorhofer
Notify danmosemsft if you want to be subscribed.

[anurse]

@ericstj this was marked as a 5.0 candidate pre-transfer. Not sure how you want to record that in dotnet/runtime, but I put it in the 5.0 milestone.

[ericstj]

I put it in the 5.0 milestone.

That's exactly what we should do.

[ericstj]

The work here is to do a pass on all the Microsoft.Extensions projects and make sure they are cross-compiling for most appropriate configurations.

We need to do things like:

1. Ensure they aren't including moving target TFMs in the package (like NetCoreAppCurrent)
2. Ensure that when configurations are excluded, as per 1, that we have an equivalent non-moving target TFM in the package (EG: netcoreapp3.0, net5.0) etc. Equivalent here means same surface area, same dependencies, same ifdefs.
3. Ensure that we include a version that has minimal dependencies. As in the case of this original report we don't want to use Microsoft.BCL packages in the latest TFM. Also we should look for cases where we can make the TFM more generic (eg: netstandard2.1 instead of netcoreapp3.0).

[ericstj]

cc @joperezr this might be a "while you're in there" change when you add .NETFramework TFMs to these libs.