Home: Package Search should limit results to compatible packages for target project(s)

[rrelyea]

Usability of NuGet inside of VS would be much improved if we could filter search results based on compatibility for the target project(s).

[Searched for an existing issue, but couldn't find. Will dupe others to this.]

[emgarten]

The reason why this isn't done today is that a large percent of packages on nuget.org contain assets compatible with everything.

Examples:

• tools/install.ps1
• build/a.targets
• lib/a.dll
• content/readme.txt

This could be solved by adding options to the UI to optionally filter to these states:

• All packages
• packages that have any compatible assets
• packages which contain compatible assets that are TFM specific
• packages that contain assets specifically for the TFM (ex: netcoreapp1.1 and not netcoreapp1.0)

This would help improve discoverability of certain packages, which is often the reason why this search filtering is requested.

[nkolev92]

This is an old duplicate issue.
https://github.com/NuGet/Home/issues/318

I will close out the other one in favor of this.

[sanny-io]

This is pretty important. It's expected that the selection of usable packages goes down when using something like .NET Core, but the fact that the small pile of things that work is lumped together with the massive pile of things that don't work is ridiculous.

[nkolev92]

We should consider PackageType as a filter too.

[frankhaugen]

This should be more of a priority, as it's getting ridiculous in the Packadge Manager. When I use Xamarin.forms, why shouldn't I have the option to hide jQuery, or other non-Xamarin/.net nugets?

It's already visible metadata, so a simple "checkbox" next to the pre-release checkbox, called "hide incompatible" would be awesome. Pre-release already do filtering so it's not that filtering don't exist.

please. I beg you, find a solution, because I like to "browse" and see what are available, (alternative Json-tools e.g.)

thank you for reading my ranting plea

[nguerrera]

Not just VS, but also dotnet add package and dotnet tool install.

[ssteiner]

This has gotten considerably worse with .NET Core 3.0. A lot of packages released with .NET core supports .NET standard 2.1. So you now get a a long list of available updates that are incompatible unless your projects already target .Net Standard 2.1 / .net core app 3.0.

[frankhaugen]

@ssteiner I've been following the Nuget development process, and it's almost abandonware. With few major changes to the clients. I concidered writing my own, but the data served up by the APIs don't have the information.

So someone in the community should take responsibility to make a custom nuget client extension and CLI so we could get this. because I can still add web nugets to my C# classlibs