[DRAFT] Behavior of out-of-box PackageReference undefined when FrameworkReference provides same reference
Description
I have searched everywhere for documentation that clearly describes what the expected behavior should be in the following scenario and there is none. The lack of a clearly defined behavior is leading to paradoxical discussions regarding the severity of packaging 6.0.0 out-of-box packages that reference out-of-box netstandard2.0 packages, where the severity is judged without considering what the correct behavior is when the out-of-box package is a referenced from a "library project" that uses netstandard2.0 TFM and the "entry point project" uses net6.0 (or any concrete target framework, but the problem is most visible now due to recent changes).
EntryPoint.csproj [net6.0]
\_ Dependencies
\_ Projects
\_ HelperLibrary.csproj [netstandard2.0]
Common.csproj [netstandard2.0]
\_ Dependencies
\_ Packages
\_ Microsft.Extensions.DependencyModel [netstandard2.0, version 6.0.0]
\_ System.Buffers [netstandard2.0, version 4.5.1]
In this scenario, System.Buffers has been "in-box" as part of the runtime libraries since .NET Core 2.1.
Reproduction Steps
EntryPoint.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<AssemblyTitle>EntryPoint</AssemblyTitle>
<OutputType>Exe</OutputType>
<TargetFrameworks>net60</TargetFrameworks>
</PropertyGroup>
<PropertyGroup>
<StartupObject>EntryPoint.Program</StartupObject>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Common\Common.csproj" />
</ItemGroup>
</Project>
Program.cs
namespace EntryPoint
{
public class Program
{
public static void Main(string[] args)
{
System.Console.Out.WriteLine("Hello, World");
}
}
}
Common.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<AssemblyTitle>Common</AssemblyTitle>
<TargetFrameworks>netstandard2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Buffers" Version="4.5.1" />
</ItemGroup>
</Project>
Run
dotnet restore EntryPoint.csproj
Known Workarounds
- Tell people not to use my project from a netstandard2.0 TFM, and that netstandard2.0 is only supposed to be used by net4.8, and proceed to look like a hacky idiot who doesn't know what he is doing packaging open source projects
- Remove support for netstandard2.0, or segregate netstandard2.0 into a special nuget package with a funny name like MyNugetPackage.Net48 that makes it abundantly clear the package only works right when used by net48 TFM.
https://github.com/dotnet/corefx/pull/36550