[Feature]: Allow Maintainers to specify additionally supported target frameworks

[HurricanKai]

NuGet Product(s) Involved

NuGet.exe, dotnet.exe

The Elevator Pitch

The list of supported frameworks becomes increasingly important, and many packages still trying to support old as well as new targets, causing the list of supported frameworks is increasingly confusing and allowing maintainers to help clear up this confusion would be much appreciated. Many packages support "old" frameworks like .NET Framework 4.x, .NET Standard 2.0, and shipping extra features with newer frameworks (.NET Core 3.1, .NET 5, .NET 6), the problem becomes that there is no clear way to indicate which frameworks are actually supported, and to what extent. For example, if a package ships 2 versions, one for .NET Standard 2.0 and one for .NET 5, a .NET 6 user will fall back to the .NET 5 implementation, but this isn't immediately clear, all they will generally see is either "my target is not supported" or with the new display on NuGet.org that it's supported via some other target, but they have no way of knowing whether the package is up-to-date with the latest features (ie Span) or whether they just support .NET Standard 2.0, and support .NET 6 just as much as .NET Framework 4.8. Package maintainers can't do anything to clear up this confusing if they don't want to duplicate their assemblies many times for all actually supported frameworks. (For example, many packages don't need to do anything to support .NET 6 to the fullest, as none of the new features are of interest to them directly)

I want to suggest a property like <PackageAdditionalTargetFrameworks>...</PackageAdditionalTargetFrameworks> that is validated on package (if .NET Framework 3.5 is specified there, but only .NET 5 is actually implemented in TargetFrameworks, an error is thrown given there is no way this is possible) and simply specifies that a target framework is officially supported, and not just incidentally. This information can then be used by UI tools like the website or IDE package managers to indicate that this package is explicitly supported, helping the user make an informed choice of which package to choose.

This property has no effect other than exposing some information to UI, the validation is really optional but nice to have.

Additional Context and Details

I'm a maintainer at Silk.NET and we have been struggling with this, I think our packages serve as a good example why users may be confused when trying to understand to what degree they are supported. For example, our Silk.NET.Vulkan package on NuGet.org.

[erdembayar]

@HurricanKai Could you please fill the top Title? Currently it's empty.

[JonDouglas]

@HurricanKai Thanks for the detailed feature request! We'd love to learn more about your scenarios and thoughts in this space. We're actively looking into compatibility scenarios as noticed by our recent blogs and features released, but perhaps a quick call might be justified? We can put a small summary here on what we covered.

https://aka.ms/talktonuget (Office hours is fine)

If a time doesn't work out, i'll write up a detailed response here to help you and the community understand what we're thinking next.

[HurricanKai]

@JonDouglas We were supposed to talk about this yesterday (for me), unfortunately I couldn't join due to some issues with corporate security, my apologies. Is there a different way to get in touch?

[JonDouglas]

Hey @HurricanKai,

Apologies to getting to this late. Sadly I didn't get a chance to talk to you online, but let's chat here.

With the new NuGet.org feature, we try to make it clear to users what is compatible in terms of what asset is provided in the package, and what is compatible given said asset provided. You can read more about this here:

https://devblogs.microsoft.com/nuget/introducing-compatible-frameworks-on-nuget-org/

Now there's a challenge here that may be greater than NuGet itself. It's about best practices and what everyone else is doing in the ecosystem as a result.

For best practices, there are docs here:

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/ https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting https://docs.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0#when-to-target-net50-or-net60-vs-netstandard

For what everyone else is doing in the ecosystem, we don't have easily shareable data today, but the expectation is that netstandard2.0 is the most targeted followed by the netX TFMs.

(Quick graph of hard to share numbers :))

The explicit support from my understanding would be whatever the author decides to provide assets for although there's a technicality of what precedence is compatible.

https://nugettools.azurewebsites.net/6.0.0/framework-precedence

With all that said, I'm not so sure about the feature request as there's a number of similar metadata/properties that exist today with similar ideas. Perhaps we just need to have more transparency on these numbers? Let me know what you think is best.

One of the next steps now that we know about TFMs on NuGet.org is to use that data and similar client properties to do what you are saying to be "explicit" in matching a TFM when searching via a project or solution for a package and installing.

[HurricanKai]

Thank you for the detailed response. First of all, I'm not sure what similar metadata/properties you are referring to, have I missed something that can help me here? I think part of the problem is that most of those links above aren't clear on what modern (-> new / updated) libs should be targeting, especially if they can't / don't want to go all the way back to netstandard2.0 the reasonable choices seem to be net6 and net5. One of the links literally has this title "When to target net5.0 or net6.0 vs. netstandard", but to me the question of "when to target net5.0 vs net6.0" is also important. Users that see only net5 as a target might think that it's not updated/doesn't use latest features. Targeting only Net6 could leave some net5 users behind for no good reason. Targeting both just bloats the assembly needlessly (there will usually be zero code difference, at least I think so).

I may be very wrong, but I think of compatible as "this may work" and supported of as "this has been tested by maintainers". To explain this a bit more I want to point out that all of those netstandard2.0 packages are compatible with Tizen(40 & 60) but nearly none will support it, either because they don't want to or because they just can't (if a bug comes up there is no way to reproduce it) so this is compatible, but is not explicitly supported. Usually .NET does a great job here and most of those packages will never have a Tizen bug, even if one went to hunt for them, but for some packages it becomes a problem.