Sdk: Any way to detect a new version of the Global Tool package and warn the user?

[CESARDELATORRE]

This probably applies to any .net core global tool.
Since a CLI tool is an independent tool, we should be able to check out that there’s a new version available (at NuGet, etc.) and at least warn the user pointing to a URL with instructions for upgrading (or do any other action in the future).
But we need a way to detect if there's a new version available. Is there any way to do this?

Ref: https://github.com/dotnet/command-line-api/issues/489

[CESARDELATORRE]

From: @loic-sharma

Yes, there's several ways to do this. I'd recommend using the registration resource (see this documentation).

For example, you can find all the versions of dotnet-format using the following endpoint: https://api.nuget.org/v3/registration3-gz-semver2/dotnet-format/index.json

I've written a library, BaGet.Protocol, that can do this.

I would check out PackageMetadataService.GetAllVersionsOrNullAsync.

[loic-sharma]

@rrelyea @anangaur This seems like a natural extension to https://github.com/NuGet/Home/wiki/Show-outdated-packages

[anangaur]

@loic-sharma 👍

Currently NuGet has dotnet list package --outdated to list outdated packages. May be dotnet tool list --outdated should do the same.

[peterhuene]

Including @wli3 for his thoughts on this.

[CESARDELATORRE]

dotnet tool list --outdated would be great, but it needs the user to be proactive on that action and run that command.

What almost every Global Tool package needs is a way to identify if the current 'running package' is outdated, doing that probably on every CLI execution (can be cached), then show a warning to the user with any message on how the user can upgrade the CLI/package tool.

[wli3]

@KathleenDollard

This is not a trivial task. Especially when there is no public API from nuget to query what is available.

Although dotnet tool update --all might be easier. Since people would expect it is an slow action.

[anangaur]

@wli3 Did you explore https://docs.microsoft.com/en-us/nuget/api/search-query-service-resource#search-for-packages?

[wli3]

@anangaur does private feed (maybe even local folders) support that? And SDK would also need to walk and parse nuget config to get a full list of feeds.

And ideally we can also query with target framework. So we could know a new package may not be compatible in advance.

[anangaur]

Hmmm.. true, it may be easier for nuget.org - not sure about other sources including local source. But since its already available for regular packages, the logic seems to be in place. I don't think target framework data is available today but shouldn't breaking changes be a new major version and hence the available version number should be indicative enough about potential breaking changes?

[wli3]

shouldn't breaking changes be a new major version and hence the available version number should be indicative enough about potential breaking changes?

This is convention based. I don't think it will be too reliable. Plus, that means we would only suggest the user to update between minor versions. This is less useful. Question on nuget package --outdated, nuget package would have a similar problem of later version stopping support of a certain TFM, what is the logic now? Show the user anyway or only show minor version

[anangaur]

We show the latest versions today and leave it to developers judgement. We did have plans to show the available versions in different colors eg. green vs. yellow vs. red (semver) but not done yet.

Btw you will have similar issues for —updateall option.

[anangaur]

I also think we had —highest-minor/patch options with — outdated but need to confirm if it was implemented (this was an intern project)

[KathleenDollard]

@anangaur Cool! I look forward to seeing what you have.

[loic-sharma]

@wli3 Did you explore https://docs.microsoft.com/en-us/nuget/api/search-query-service-resource#search-for-packages?

I would not recommend implementing this using the search API. Server implementations can interpret search queries however they want. For example, searching nuget.org for packageId:Newtonsoft.Json will filter results to just Newtonsoft.Json... but this isn't part of the protocol, so different servers may have different results. We shouldn't depend on "undefined" behavior.

Instead, I'd recommend the "Package Metadata" resource. This resource is supported by all kinds of feeds including nuget.org, MyGet, AzDO, Sleet, and BaGet.

[anangaur]

@KathleenDollard Its already available with latest .NET SDK. I created a sample project and added 3 NuGet packages to it - all with version lower than highest available. Here is the output of my commands:

dotnet version:

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.2.203
 Commit:    e5bab63eca

dotnet list package:

> dotnet list package
Project 'SampleDemonstrateListCommand' has the following package references
   [netcoreapp2.1]:
   Top-level Package               Requested   Resolved
   > EntityFramework               6.1.2       6.1.2
   > Microsoft.NETCore.App   (A)   [2.1.0, )   2.1.0
   > Newtonsoft.Json               11.0.1      11.0.1
   > NUnit                         3.9.0       3.9.0

(A) : Auto-referenced package.

dotnet list package --outdated :

> dotnet list package --outdated

The following sources were used:
   https://api.nuget.org/v3/index.json
   C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Project `SampleDemonstrateListCommand` has the following updates to its packages
   [netcoreapp2.1]:
   Top-level Package      Requested   Resolved   Latest
   > EntityFramework      6.1.2       6.1.2      6.2.0
   > Newtonsoft.Json      11.0.1      11.0.1     12.0.1
   > NUnit                3.9.0       3.9.0      3.11.0

dotnet list package --outdated --highest-minor // see the diff in Latest version for Newtonsoft.Json:

> dotnet list package --outdated --highest-minor

The following sources were used:
   https://api.nuget.org/v3/index.json
   C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Project `SampleDemonstrateListCommand` has the following updates to its packages
   [netcoreapp2.1]:
   Top-level Package      Requested   Resolved   Latest
   > EntityFramework      6.1.2       6.1.2      6.2.0
   > Newtonsoft.Json      11.0.1      11.0.1     11.0.2
   > NUnit                3.9.0       3.9.0      3.11.0