.NET 5 - dotnet tool support for WinForms applications targeting net5.0-windows

[guidemetothemoon]

Hello.

I have a question regarding dotnet tool supprot for WinForms applications: we have been planning to lift our .NET Core 3.1 Windows Forms applications that are now being packaged as dotnet tools to .NET 5 but this will mean that the target framework for those applications will be .net5.0-windows.

The problem is then that we will not be able to package those apps as dotnet tools anymore, ref. following error message coming from the build pipeline:
C:\Program Files\dotnet\sdk\5.0.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.PackTool.targets(95,5): error NETSDK1146: PackAsTool does not support TargetPlatformIdentifier being set. For example, TargetFramework cannot be net5.0-windows, only net5.0. PackAsTool also does not support UseWPF or UseWindowsForms when targeting .NET 5 and higher.

Unfortunately I'm not able to find more detailed information or any documentation saying that it's not supported and what alternative approaches are recommended.
Can someone please clarify this for me?

Thanks in advance!

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[tthiery]

@marcpopMSFT I have the same issue when multi-targeting a console application with <TargetFrameworks>net5.0-windows10.0.19041.0;net5.0</TargetFrameworks> (I use WinRT Bluetooth Stack on Windows and other stacks which do not need a framework).

I am very confused about this considering that dotnet tool install -g has a switch to specify the framework (--framework)

[marcpopMSFT]

@wli3 do we have this limitation documented anywhere outside of the error message?

[wli3]

Any suggestion to make the error message better? At this point, anything net5.0-windows will not be supported. And there is no easy way to pack only one specific TFM to tools.

The root cause is #12055

[tthiery]

I think the error message is quite alright. The "also" of the WPF/WinForms message is quite correct, but I overread it the first time.

Independent of the error message, it is the mismatch against the expectations which is the problem 😀. We see a CLI parameter and think we can just pack it like a regular multi-target NuGet.