- 17 Jun 2021
- 3 Minutes to read
Problems With My NuGet.org Connectors
- Updated on 17 Jun 2021
- 3 Minutes to read
This article applies NuGet.org deprecating API features on March 9, 2021, and may help explain problems with connectors as a result.
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.
NuGet API 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.
On March 9th, 2021, NuGet.org began 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 upgraded to ProGet 5.3+, you are not directly affected by this, but we recommend making sure the v3 API is enabled in ProGet on the feed's Manage Feed page, and configuring your NuGet clients (and Visual Studio) to use the new v3 API URL for your feeds.
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. 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.