Package discovery: Show and search by TFM/package-compatibility

[hickford]

A feature request: I'd like to browse packages compatible with .NET Core

Most the packages on https://www.nuget.org/packages seem not to be, so it would be useful to shortlist those that are

>dotnet restore
Package Microsoft.Net.Http 2.2.29 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). 
One or more packages are incompatible with .NETCoreApp,Version=v1.0.

I want to search nuget.org by target framework.

Recently Triaged Issues

All issues in this section should be triaged by the v-team into one of their business objectives or features.

• Create an Engineering Spec for Phase 1 of Search-by-TFM #8863
• Prototype adding asset frameworks from the catalog in Catalog2AzureSearch #8864
• Prototype including Computed Frameworks in the supportedFrameworks search index field #8865

[ghost]

It is extremely necessary that we have a separate list for .NET Core compatible packages to allow ease of use.

[praveenksharma]

It is a must. Please implement it in some way. I wasted so much time today figuring out which dapper version is dotnet core and which is not.

[feliwir]

Yea I can't really work with nuget without that feature

[skofman1]

@harikmenon ?

[jdehaan]

Not only for .Net core but add tags for all supported platforms. It seems to me this could be easily done just after the upload during the package registration process in the db by looking at the folders present inside the lib/ folder. Having that info in the db, allows then adding a feature in the gallery to allow filtering per tags. Really looking forward to having that great feature!

[lgreenlee]

Yes - this is an issue. Visually browsing I cannot see if packages are compatible with .NET Core, thus it is impossible to select the right packages to install without actually attempting the install. It would also be nice in applications that use NuGet, if they could also filter by target runtime. Frequently versions are shown that cannot be restored on a .NET Core platform.

[adamralph]

Issues #3098 (this one), #2936 and #2787 all seem to be using different words to talk about the same feature.

[poimis]

"compatible with .NET Core" is not the right wording for this issue as there are many cores already. We need to be able to search by target tfm, I.E. "gimme packages compatible with .NET Standard 1.4". Or "gimme packages compatible with PCL profile111" etc.

[nbarbettini]

Agreed, being able to do advanced filtering by TFMs would be great.

[anavarro9731]

Agreed, completely

[mrnickel]

I really believe it would be a boon to the .net community if this were implemented.

By way of an example:

Just today I wanted to replace an "old" piece of Java software I had written to run on .NET core (C#). This piece of technology CURRENTLY has a dependency on Beanstalkd. It would have been VERY helpful for me to be able to limit my search on Nuget.org for packages that were compatible with core.

[karann-msft]

@anangaur

[msollicito]

I agree - its almost impossible to program to .net core because this does not exist

[MaximCrabbe]

Not impossible, just a pain in the ***. Google is better to find nugget .net core packages then nugget search itself... This is sad that this major feature is missing...

[msollicito]

Definitely we need this list - I am spending so much time trying to work out which nuget package is .net core compatible!!!!!!!

[stanuku]

Any updates please?

[anangaur]

We have been thinking about this feature in general. For search by TFMs (and other compats) from within VS, the issue is here: NuGet/Home#4071

This is in our backlog in next set of features to design and implement.

[adamralph]

from within VS

Why only from within VS? The .NET ecosystem is bigger than VS now, specially with .NET Core encouraging development on platforms which can't even run VS.

[anangaur]

@adamralph Agree. The issue I referenced talked about the VS scenario.
When we look at solving the improved search, it would be a general approach that will work across CLIs and also include web search.

[coultonluke]

Yes please, please implement this. Nuget seems like a bit of a minefield in VS.

[mattleibow]

What will be cool is if I could search for packages that are compatible with a particular TFM, but consider the other files in the package.

For example, let's say I want to search for "markdown" for "Xamarin.iOS".

NuGet world has several packages:

• CoolMarkdown that supports net45
• GreatMarkdown that supports net45 and netstandard1.3
• AppleMarkdown that supports Xamarin.iOS

I would like my results to show GreatMarkdown and AppleMarkdown because:

• AppleMarkdown supports Xamarin.iOS
• GreatMarkdown supports netstandard1.3, which is supported by Xamarin.iOS

This should be possible to detect, because when installing a package, it can do this.

[abelykh0]

Since the feature request "LTS/high-level version management within NuGet" (https://developercommunity2.visualstudio.com/t/LTShigh-level-version-management-within/514054?entry=suggestion&ref=native&refTime=1620221915643&refUserId=ea4f1b9b-d64c-6362-b241-e9b5ae54f89f) marked as a duplicate of this one, I would like to mention it. For example, I should be able to filter versions targeting v3.1 LTS vs 5.0, which is not LTS.

[adamralph]

@abelykh0 how is "3.1 LTS vs 5.0" different from "3.1 vs 5.0"?

[abelykh0]

@abelykh0 how is "3.1 LTS vs 5.0" different from "3.1 vs 5.0"?
No different, why?

[adamralph]

@abelykh0 then why mention LTS here?

[JonDouglas]

Hi friends,

Now with .NET 6 out of the door, we'd like to give this issue some attention. I've already created some MVPs & proposals for this work, but I could use your help.

Here's some screenshots of the experience we are thinking about:

Filter by generations of .NET & supported platforms:

Use version filters for exact matches:

These packages of course would be decorated with the respective Target Frameworks and Platforms they support on the details page & search page. You would be able to navigate directly to a search of that TFM / Platform + Version by clicking the badge:

Target Framework Monikers (TFM) on details:

Full Mockup Showing Everything Together:

There's many things to consider such as not populating every TFM for search results and maybe only showing the most popular TFMs badges. This is where we can use some help & your feedback! Feel free to drop some support on this comment with a 👍 or 👎 to help us with the direction & provide some feedback below as a comment.

If there's any examples of other ecosystems doing this well, drop a screenshot for us to look through! We'll be posting a functional spec shortly, so we'd love your feedback there as well.

Lastly, we'd also love to talk to you over a quick call to get your feedback on filtering as well. Please schedule a call with us below:

https://aka.ms/talktonuget (Advanced Filters)

Thanks all!

[JonDouglas]

Hello friends,

I've posted a proposal that has much more depth than the comment above. You can read through the design for this here and provide your feedback on the PR:

NuGet/Home#11374

Would really appreciate all of your comments, feedback, and even concerns about this work to help us ensure we are working on the right things.

Thanks all!

[vbjay]

NuGet/Home#4071 (comment) Not just search but update needs to be handled too.

[OskarKlintrot]

Sorry if this is a stupid question but is this issue only for support on nuget.org or also in NuGet.Client (NuGet.Protocol)? I would love to have the compatible frameworks on NuGet.Protocol.Core.Types.IPackageSearchMetadata so I can retrive them with PackageMetadataResource!

[loic-sharma]

@OskarKlintrot Not at all, it's an excellent question! We will definitely add this info to the NuGet protocol so that clients like Visual Studio can also show this information. However, we are very careful (aka slow) when updating the NuGet protocol as we want to make sure we can support customers for long periods of time.

For now, I recommend copying nuget.org's logic into your own app:

1. Download a package
2. Read the package's metadata
3. Compute its compatible frameworks (see: 1, 2, 3, 4)

[OskarKlintrot]

Thanks @loic-sharma! I did something similar for https://github.com/OskarKlintrot/UpdatR to get the supported frameworks for dotnet tools. I noticed that all packages I use (except coverlet.collector) have IPackageSearchMetadata.DependencySets set so I can use CompatibilityProvider.IsCompatible for those. Once I got it working for tools, I realized that I had been barking up the wrong tree... My goal was to update dotnet-ef to the same version as in the csproj's but dotnet-ef targets netcoreapp3.1 so that didn't work. In the end I just bodged something together but it was a fun exercise anyway. Sorry for going a bit ot :)

[JonDouglas]

https://devblogs.microsoft.com/nuget/introducing-search-by-target-framework-on-nuget-org/

🚢 🐿️ 🎉