When TargetFramework=net5.0-windows, dotnet pack uses net5.0-windows7.0 instead

I can’t tell if this is by design or if it’s a bug, and I couldn’t find any documentation via search engines that would explain this. I also read the Target Framework Names in .NET 5 design spec and didn’t see any mention of this behavior there.

When running dotnet build on a .NET 5 WPF app or .NET 5 Windows Forms App with a TargetFramework set to net5.0-windows, all artifacts are correctly written to bin\{Configuration}\net5.0-windows as expected.

However, when running dotnet pack on the same project, the artifacts in the .nupkg are stored in /lib/net5.0-windows7.0 instead of /lib/net5.0-windows which is what one would expect.

To reproduce:

mkdir repro
cd repro
dotnet new wpf --framework net5.0
dotnet pack repro.csproj

repro.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
  </PropertyGroup>

</Project>

Expectation

The expectation is that dotnet pack would honor exactly what has been defined in the .csproj and exactly what is written to the disk… Which leads me to believe that this could be a bug in dotnet pack.

If this is by design, then I’d like to put in a feature request to throw an error that prevents devs from using net5.0-windows in WPF & WinForms projects and force developers to be specific with net5.0-windows7.0 or net5.0-windows10.0.17763.0 instead, because otherwise it is very confusing to have net5.0-windows in the project, net5.0-windows on disk in the build output, but then a different folder in the NuGet package.

---

C:\Users\augustoproiete>dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.1.802 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  3.1.101 [C:\Program Files\dotnet\sdk]
  3.1.102 [C:\Program Files\dotnet\sdk]
  3.1.302 [C:\Program Files\dotnet\sdk]
  3.1.404 [C:\Program Files\dotnet\sdk]
  5.0.100 [C:\Program Files\dotnet\sdk]

[Skyppid]

I had the same phenomenon and when I tried to install these packages in a .NET 5 app, it told me that “net5.0” and “net.5.0-windows7.0” aren’t compatible. All my projects where “net5.0-windows” actually, though.

[nkolev92]

The pack behavior described in spec is carries the gist of platform versions are required in packages, but doesn’t use the terminology that was implemented.

See

TFM has an OS but no OS version. If the user omits the OS version number from the project's <TargetFramework> property, all usages of the TFM should not contain an OS version number, including the project's output directory, the lib folder in the NuGet package, and other corresponding entries in the .nuspec. However, the effective OS version will be recorded in the .nuspec's <platform> element that corresponds to the TFM.

I think this is ok, because the general spec can’t reasonable call out all technical details.

I think it’d be nice to have specific docs describing this behavior.