Azure DevOps packages are ignored for version auto-complete

[tverboon]

I am currently using the 0.43-dev version. Our internal package version are not auto-completed anymore. I am not sure if MS has changed something on their end. Here are some logs:

[Info  - 7:52:19 AM] Using MSBuild engine v6.0.100 from "/usr/local/share/dotnet/sdk/6.0.100/".
[Info  - 7:52:19 AM] 2 package sources configured for project "SuperSecret.csproj".
[Info  - 7:52:19 AM]   Locally-configured package source "nuget.org" (v3) => https://api.nuget.org/v3/index.json
[Info  - 7:52:19 AM]   Locally-configured package source "VSTS" (v2) => https://***.pkgs.visualstudio.com/_packaging/Internal/nuget/v3/index.json
[Warn  - 7:52:19 AM]     Ignoring configured package source "VSTS" ("https://***.pkgs.visualstudio.com/_packaging/Internal/nuget/v3/index.json") because it does not appear to support a compatible version of the NuGet auto-complete API.
[Info  - 7:52:20 AM] Successfully loaded project "

[tintoy]

Yeah sorry about that - for a long time we were on a very old version of the NuGet client libraries; once we upgraded to a relatively recent version (to add support for authenticated package feeds), we lost support for v2 of the NuGet API. Azure Pipelines’ feed end-point implements the v3 search API but not the the v3 auto-complete API (which has the correct behaviour for listing package completions).

Before I added that error message it would simply fail to show any completions and there would be an exception in the log:

#39

One possible workaround might be to create a MyGet feed and add your Azure Pipelines feed to it as an upstream feed.

[tverboon]

You got to move forward, I completely understand.

Do you know if GitHub Packages supports the auto-complete API?

[tintoy]

I’m not sure but it wouldn’t be hard to find out - the NuGet API includes an API for listing APIs 🙂

[tintoy]

https://docs.microsoft.com/en-us/nuget/api/service-index

Do you know what the GitHub feed URL is? Sorry, on my phone at the moment 🙂

[tverboon]

This is my feed output:

{
      "version": "3.0.0-beta.1",
      "resources": [
        {
          "@id": "https://nuget.pkg.github.com/tverboon/download",
          "@type": "PackageBaseAddress/3.0.0",
          "comment": "Get package content (.nupkg)."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon/query",
          "@type": "SearchQueryService",
          "comment": "Filter and search for packages by keyword."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon/query",
          "@type": "SearchQueryService/3.0.0-beta",
          "comment": "Filter and search for packages by keyword."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon/query",
          "@type": "SearchQueryService/3.0.0-rc",
          "comment": "Filter and search for packages by keyword."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon",
          "@type": "PackagePublish/2.0.0",
          "comment": "Push and delete (or unlist) packages."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon",
          "@type": "RegistrationsBaseUrl",
          "comment": "Get package metadata."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon",
          "@type": "RegistrationsBaseUrl/3.0.0-beta",
          "comment": "Get package metadata."
        },
        {
          "@id": "https://nuget.pkg.github.com/tverboon",
          "@type": "RegistrationsBaseUrl/3.0.0-rc",
          "comment": "Get package metadata."
        }
      ]
    }

I guess not.

[tintoy]

Hmm, it seems a few feeds don’t support auto-complete; I might be able add a per-feed setting to use the search API instead of the auto-complete API but I suspect it may perform more poorly than the auto-complete API. I’ll have a think about what can be done…

[tverboon]

Yeah, I was also looking at the Search API. It's a lot more data. Not sure what the impact is on the server side.

The MS docs state the following:

The interpretation of the search query (e.g. the tokenization of the search terms) is determined by the server implementation but the general expectation is that the search query is used for matching package IDs, titles, descriptions, and tags. Other package metadata fields may also be considered.

Depending on the server side implementation, it could be combined with a take=1. I might hope the first record is the matching id, but that really depends on the server side query.