exact match and version search for nuget.exe list command

[jjanuszkiewicz]

(See https://nuget.codeplex.com/workitem/2130 for a related discussion)

I'd like to be able to find a specific package (exact match on package ID) using the nuget.exe command line client. I'd also like to be able to find a specific version of the package (to check if that version exists in the feed).

Something like:

# list the most recent version of MyPackage, matching by exact package ID
nuget.exe list MyPackage -ExactMatch

# list all versions of MyPackage, matching by exact package ID
nuget.exe list MyPackage -ExactMatch -AllVersions

# list the provided version of MyPackage, matching by exact package ID
nuget.exe list MyPackage -ExactMatch -Version 1.2.3.4

So in short, the -ExactMatch option would cause the search term to be an exact match on the package ID. The -Version option (which probably only makes sense with -ExactMatch) would cause only the specified version to be listed (if it exists).

I would use this in scripts (outside of Visual Studio) instead of having to rely on hacks (e.g. trying to install a specific version of the package and checking if it succeeds or not).

[DannyMeister]

I have the additional use cases for the -Version option:

# list the available compatible versions of MyPackage via version wildcard
nuget.exe list MyPackage -ExactMatch -Version 1.2.*

# find the available beta releases for a specific version of MyPackage
nuget.exe list MyPackage -ExactMatch -Version 2.0.0-beta*

I would think probably anything supported by the Version attribute of <PackageReference> would probably make sense, though I'm not sure whether that currently supports my beta requirement.

[Alchemy86]

Is this possible yet at all

[nigurr]

Hi,

We have similar case where we want to get all versions of specific package.
We don't need to even to search for package as we know exactly what we are looking for.

[medianick]

Here's my workaround:

nuget list SomePackage -AllVersions | findstr /E " 1.2.3"

This will set ERRORLEVEL to 0 if SomePackage 1.2.3 exists in the source, but 1 if it is not. The combination of the /E switch (match end of line only) and the space before the version causes an exact match of the full version number rather than erroneously matching a substring of it.

[jstutson]

This is such a common need in script publishing, especially for CI builds. I'm extremely surprised there is no method for asking a remote repo whether it has a package at a given version.

[nigurr]

Surprised to see there's not any traction nor feedback from the owners. It's being there for more than an year

@jainaashish @mishra14

[jainaashish]

Team (with limited resources) have been occupied with other priority items which is why we haven't got time to discuss this issue or make any progress.

Besides, this is not going to be a straight implementation of some additional flags... current search apis doesn't support restricting it to exact package id or passing specific version so it'd either require protocol changes or additional filtering on client side. Either way it has to be discussed against multiple options and decides the right course of action.

One alternate nuget list id:<Exact_Package_Id> -AllVersion and then find specific version.

[adamrodger]

One alternate nuget list id:<Exact_Package_Id> -AllVersion and then find specific version.

This doesn't work without additional parsing of the version number client side. For example if you have versions 1.9.9, 1.9.10 and 1.10.0 then you can't just sort them and pick the last one to get the latest for a particular version (e.g. 1.9.x or 1.x). You need to parse the individual segments and sort them to create the correct semantic ordering and then pick the latest.

Edit: I do it like this using Unix sort with the -V argument to do a version sort:

package_id=my.package.id
version_prefix=2.
nuget list $package_id -AllVersions | cut -d' ' -f 2 | grep ^$version_prefix | sort -V | tail -1

That doesn't work for packages with IDs that can be substrings of other packages though (like Newtonsoft.Json or xUnit). If your package happens to only return one result when searching by ID though, then it works fine.

[karann-msft]

@jjanuszkiewicz @nigurr @jstutson - can you all please elaborate your respective scenarios.
For example - when you know the exact Id and version of an existing package published to nuget.org, what do you gain by a command that is merely echoing its existence which you probably already know it exists.

[DannyMeister]

I believe that in the case of @nigurr and myself, and probably some of @jjanuszkiewicz cases, the exact version isn't always known. But when I try to list package versions for Foo to select the most appropriate one, i don't want to get package FooBar in my results. This is making CI scripts more difficult. I am using nuget packages for distribution of deploy time dependencies, not just compile time, so I don't get to take advantage of the extra capabilities of package references that msbuild/vs figures out for you, but I sorely need them. The -Version flag with ranges would make this all a breeze so I don't have to do my own semantic version parsing and sorting. And if it supports ranges, it might as well support the full version number so that our scripts don't need conditional logic dependent upon the values in the config files they are processing.

[jjanuszkiewicz]

@karann-msft My scenario is not related to nuget.org at all, but to publishing to our private Nuget feed (although it would apply to nuget.org the same if we published public packages).
At my company, we have a build process in which we build a number of Nuget packages. Our build numbers are (more or less) autoincrementing, but we don't want every build to produce a new version of a package if the source code for that package has not changed. So it's possible that consecutive builds produce the same package versions for some packages. Then after the packages are built, we want to push them to our feed, but the problem is that we can't check if a given package already exists (i.e. was already pushed from a previous build). We instead have to configure our feed to disallow overwriting existing packages and handle the errors that are returned when the second build tries to push an already-existing package.
We would prefer to be able to check if that package exists and if it does, don't attempt to push it, rather than having to rely on the feed returning specific errors. The current logic is brittle as we have to parse the returned error code (e.g. HTTP 403) and message to see if this is the known scenario that we can ignore, or some other error that should actually cause our build to fail.

Hope this helps, I can elaborate more if it's unclear.

[nkolev92]

@jjanuszkiewicz

We instead have to configure our feed to disallow overwriting existing packages and handle the errors that are returned when the second build tries to push an already-existing package.

fwiw a skip duplicate switch has been added to nuget.exe #1630 courtesy of @donnie-msft

It's usually less error prone if you don't allow overwriting of packages on your feeds.

I know this is lateral to this ask, but just a suggestion to improve your workflow with what's currently in place.

[BertanAygun]

This is something that caused an issue on our scripts today too when we added another package that is prefixed by name of another package. Now "nuget list packageName" was returning all packages that start with "packageName". It would be great to have an option to return only packages with exact name match.

[logiclrd]

This has been a feature request since at least 2014, maybe even earlier. How is it still not possible to query a specific package by exact match on its package id from the NuGet CLI? 🤔

[donnie-msft]

Surprised this issue makes no mention of the Package Manager Console commands (specifically Find-Package). Do these APIs provide what you feel is missing in nuget list?

Of particular interest would be the two options for specifying an exact package ID

1. prefix the name of the package with packageId: (packageId:<name of package>).
2. And similarly, the -ExactMatch option.

Some example behaviors:
Default behavior if you provide neither option is to query the source(s) for the provided keywords anywhere within the Package Name. Newtonsoft would match both Newtonsoft.Json and NServiceBus.Newtonsoft.Json.
find-package -Source nuget.org -id newtonsoft

Adding "packageId:" triggers an exact-match search (on nuget.org, this will filter results on the server before returning to the Client).
find-package -Source nuget.org packageId:newtonsoft returns no results (no package exists with the exact name, newtonsoft).

find-package -Source nuget.org packageId:newtonsoft.json returns exactly 1 result.

Another option is -ExactMatch for specifying a search as being an exact match. This will load all results on the Client, then filter them out client-side; therefore, it can be much slower
find-package newtonsoft.json -Source nuget.org -ExactMatch

.

[logiclrd]

My need involved a script running in an Azure DevOps Build Pipeline script. Can the Package Manager Console's Find-Package be accessed outside of that context??

[kumaresan-subramani]

https://www.nuget.org/packages/dotnet-search/

This helps for me..!

[logiclrd]

@kumaresan-subramani How do you use this tool to do a search that is an exact match search on package name and/or version?

[jstutson]

To answer the question of use-case, for me need was to check if a package version existed prior to attempting to publish that version during CI/CD. The alternative was to blindly attempt to publish the package and then parse the 400 error response from proget/artifactory for the duplicate exception if it occurred. Or, we could do as stated above and get all matches then manually parse through them.

[logiclrd]

My use case goes a step further, I want to query what the latest version is of that exact package so that the build can automatically increment the version number, using the NuGet package repository itself to store the version state.

[pavelpe]

Surprised this issue makes no mention of the Package Manager Console commands (specifically Find-Package). Do these APIs provide what you feel is missing in nuget list?

Of particular interest would be the two options for specifying an exact package ID

1. prefix the name of the package with packageId: (packageId:<name of package>).
2. And similarly, the -ExactMatch option.

Some example behaviors:
Default behavior if you provide neither option is to query the source(s) for the provided keywords anywhere within the Package Name. Newtonsoft would match both Newtonsoft.Json and NServiceBus.Newtonsoft.Json.
find-package -Source nuget.org -id newtonsoft

Adding "packageId:" triggers an exact-match search (on nuget.org, this will filter results on the server before returning to the Client).
find-package -Source nuget.org packageId:newtonsoft returns no results (no package exists with the exact name, newtonsoft).

find-package -Source nuget.org packageId:newtonsoft.json returns exactly 1 result.

Another option is -ExactMatch for specifying a search as being an exact match. This will load all results on the Client, then filter them out client-side; therefore, it can be much slower
find-package newtonsoft.json -Source nuget.org -ExactMatch

.

This can't help you to extract License URL for example.
I use the method you proposed to check first if specific Nuget Id (and version) exists, and then I try to get the details
nuget list $pkgName -Verbosity detailed of this nuget.

There I can extract the license URL.
But running nuget list is always ends with getting huge amount of irrelevant data:

[DanielDantas]

Hey guys, try using the NuGet API instead of the cli commands on your script

$url = 'https://api.nuget.org/v3/registration5-gz-semver2/PACKAGE_ID_GOES_HERE/index.json'
$res = Invoke-RestMethod $url
$res.items.items.catalogEntry.version

This will list all the versions for that specific package.

If you just want to check if a specific version is listed for that specific package just do the following

$url = 'https://api.nuget.org/v3/registration5-gz-semver2/PACKAGE_ID_GOES_HERE/VERSION_GOES_HERE.json'
$res = Invoke-RestMethod $url
$res.listed

You can learn more about it here: https://docs.microsoft.com/en-us/nuget/api/registration-base-url-resource

Let me also link you to this answer that better explains how you can properly use the NuGet APIs on your script: https://stackoverflow.com/a/60659206/7846946

Hope this helps!

[jairbubbles]

Thx for sharing @DanielDantas

[jairbubbles]

Please note that you can also use:

https://api.nuget.org/v3-flatcontainer/newtonsoft.json/index.json

Doc: https://docs.microsoft.com/en-us/nuget/api/package-base-address-resource

The response is a lot smaller. It's available on nuget.org but sadly not on Artifactory. (tested on version 6.20.0)

[aortiz-msft]

I just want to make sure that folks are aware of the PackageId:{id} parameter which matches the package ID in an exact manner: https://docs.microsoft.com/en-us/nuget/consume-packages/finding-and-choosing-packages#search-syntax. The version matching is missing in the command today.

[Jaurocha]

The PackageId:{id} parameter does not work. In any form. Adding it just give no result back.
The list method just behaves like a simple contains. And the added parameters seem to be interpreted as a part of the package name.

I have a BusinessLogic package and it among other have its IOC setup in a separate package. And I named it BusinessLogicAutoFacSetup this gave off course multiple hits. So I hoped that the search did a Begins with so I renamed the package AutoFacSetupBusinessLogic but I still get multiple results, both BusinessLogic and AutoFacSetupBusinessLogic when trying to list BusinessLogic.

Is there really no way to do a literal search with nuget.exe

[matthewjones555]

Is there really no way to do a literal search with nuget.exe

I've been experiencing exactly the same pain. I belived the PackageId trick is only applicable if you're using a v3 feed that also has that change. I'm slumming it on a v2 feed, and there appears to be no client based way of doing this. It would be nice if they added support instead of relying on the API for it, as it has to support multiple APIs, and file system feeds.

[nkolev92]

Fixed by NuGet/NuGet.Client#5580.

cc @Nigusu-Allehu

[Pxtl]

@nkolev92 since an issue in nuget.exe is closed by implementing it in dotnet package search, should I understand that nuget.exe search is deprecated? Is nuget.exe in general deprecated?

[nkolev92]

At this time, we're only adding the option to dotnet package search.
I don't expect we'll be porting it to nuget.exe.
Consider using dotnet package search.

[Pxtl]

Yes, I've already switched my code over to dotnet package search and it works great, thanks. I was just wondering if more generally I should be avoiding use of nuget.exe when building new devops pipeline code?

[nkolev92]

The .NET SDK carries both restore & build tooling, and is cross platform.
If all you are building are SDK style projects only, use dotnet.exe directly.

[Pxtl]

The main thing I'm still using "nuget.exe" is for simple by-name downloading of nuget packages (from nuget.org, psgallery, and others) for PowerShell scripts, starting with simply nuget.exe install <modulename> -source <source>.

As these scripts mature I've been moving them to using nuget.config+packages.config to bundle up their list of dotnet dependencies.

Is nuget.exe not the right tool for the job for this workflow? It works much better than PowershelGet/PackageManagement built into PowerShell.

After this conversation I'm looking at the possibility of using a NoTargets .csproj with PackageReference entries to replace the packages.config since that seems like the future.

[nkolev92]

After this conversation I'm looking at the possibility of using a NoTargets .csproj with PackageReference entries to replace the packages.config since that seems like the future.

Use a NoTargets SDK, but use PackageDownload instead of PackageReference.

• No compat checking
• No transitives download

Perfect for those transient scenarios where you're still just downloading packages for legacy reasons.

https://learn.microsoft.com/en-us/nuget/consume-packages/packagedownload-functionality