Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] Behavior of out-of-box PackageReference undefined when FrameworkReference provides same reference #9

Open
jzabroski opened this issue Nov 24, 2021 · 1 comment

Comments

@jzabroski
Copy link
Owner

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

  1. 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
  2. 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.
@jzabroski
Copy link
Owner Author

https://github.com/dotnet/corefx/pull/36550

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant