Problems With My Connectors

KB#1800: Last Updated December 10, 2020

My NuGet feed is suddenly empty and not showing remote packages

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


NuGet is a package format developed by Microsoft to distribute free and open-source .NET libraries. Typically, these packages are publicly available on, 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 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 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.

On March 9th, 2021, will begin blocking select endpoints used by 3rd party clients like ProGet. For more information, please see Microsoft’s blog article Custom V2 OData queries will be deprecated March 9, 2021.

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 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. Unsupported queries can be viewed in the Diagnostics Center under the message category of NuGet v2 Bad Requests. This message can be dismissed via each feed’s Manage Feed page.

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: 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

March 9, 2021: will officially deprecate custom V2 features