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

[augustoproiete]

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.

[mrbiglari]

I had the same issue as @Skyppid , in my case it was because I had a project with _.net5.0_ referencing _.net5.0-windows_ projects.

I got it resolved by just changing the _.net5.0_ to _.net5.0-windows_ as well.

[augustoproiete]

Confirmed by @zkat on Twitter that this is by design.

[augustoproiete]

I'll leave this issue open as a suggestion to add some consistency here between the build output, and the NuGet packaged library, either on the .NET SDK side or on the NuGet side.

When developing libraries that should be consumed by Windows Desktop apps, and given that I defined net5.0-windows in my project, I'd expect NuGet to also store the files under net5.0-windows, but it doesn't:

However, if set the TargetFramework in my project to net5.0-windows7.0, then my build output now uses net5.0-windows7.0 and now it matches the NuGet package folder structure.

---

One alternative could be modifying the logic of the warning NETSDK1136 that requires net5.0-windows when the project has <UseWPF>true</UseWPF> or <UseWindowsForms>true</UseWindowsForms>, to require net5.0-windows7.0 instead, when the user specified net5.0-windows as the TFM.

Error NETSDK1136 The target platform must be set to Windows (usually by including '-windows' in the TargetFramework property) when using Windows Forms or WPF, or referencing projects or packages that do so.

Another alternative could be changing NuGet to use net5.0-windows instead of net5.0-windows7.0 and have it understand that it's the same thing.

[dsplaisted]

As mentioned, this is by design.

@zkat @nkolev92 is there an explanation to link to about how / why this works?

[zkat]

I looked through https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md but didn't find anywhere where this was actually documented. I don't think we have it documented anywhere but in our heads right now. Did you have anything, @terrajobst ?

[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.