Problems With My NuGet.org Connectors

KB#1800: Last Updated November 4, 2020

My NuGet feed is suddenly empty and not showing remote packages

If you have a connector to NuGet.org configured in ProGet 5.2 or earlier, then it may suddenly stop working and not return any packages. This is due to an API change at NuGet.org, and the only solution is to upgrade to ProGet 5.3 or later. You may also temporarily work around the problem by disabling your connector filters.

My NuGet connector shows healthy, but it has the wrong package count

If you have a connector to NuGet.org configured in ProGet 5.2 or earlier, you may notice a healthy connector status but an incorrect package count. NuGet.org has deprecated its previous queries for checking health and count of NuGet packages because it is very taxing to the NuGet servers. Going forward, NuGet.org will display a fixed number of packages when querying for health statuses.

Background

NuGet is a package format developed by Microsoft to distribute free and open-source .NET libraries. Typically, these packages are publicly available on NuGet.org, and are consumed by Visual Studio or the nuget.exe command-line client.

When NuGet was released, they needed a client/server protocol that would allow users to query packages, fetch package metadata, and download package artifacts. The logical choice at the time was OData: by exposing their Entity Framework model over OData, the NuGet client could run any query on their database, using OData as the protocol. The problem with this architecture is that every query made a direct database query. This caused NuGet.org to start to have some pretty major performance issues causing the server to slow to a crawl under heavy loads.

In early 2016, NuGet introduced their third version of the API. This API is centered around a static catalog of NuGet package metadata and a Lucene-based search engine, decoupling the increase in NuGet usage from the increase in database load. This has helped to improve the overall performance of NuGet.org drastically.

In late 2019, NuGet announced that they are going to start deprecating features of their API v2 (WCF OData) to make the API a stable and performant shim on top of API v3, ensuring the data returned in both API’s are identical while not breaking backward compatibility. The first step of this was to implement throttling on API v2 usage. The second step of this process will be eliminating non-performant queries that are not in a 1 to 1 parity with API v3.

How Does This Affect ProGet

If you have already upgrade to ProGet 5.3+, you are not affected by this. In ProGet 5.3, we introduced the implementation of the NuGet v3 API as well as enabled connectors to use the v3 API to connect to NuGet.org. ProGet 5.3 also has backward compatibility for the NuGet v2 API. This means any v2 client connecting to ProGet to query, push, pull, etc. will not be affected as long as those packages are local or their connector is using the v3 API. If you are still using a v2 based connector, ProGet 5.3 (via PG-1847) will display a message if an unsupported query is used.

If you are using ProGet 5.2 or below you will notice some features within ProGet’s connectors will no longer work (listed above). Nothing will change with your local packages, they will continue to work as they have always worked. Connector health may return okay, but the total number of NuGet packages may not be the correct number of packages.

Current Status

November 2020: NuGet.org will begin brownout periods to test how this change will affect customers.

  • November 11 2020 – 3 time slots in a 24 hour period. Each slot will last for 4 hours
  • November 17-18 2020 – 48 hour period

January 2021: NuGet.org will officially deprecate V2 features