search

OneGet / NuGetProvider

NuGet Provider for OneGet. Works on Nano Server.
MIT License
31 stars 24 forks source link

40 NuGet bug #30

Open jeopal opened 6 years ago

jeopal commented 6 years ago

When 40 versions of a NuGet have been published to a NuGet v2 feed, Find-Package, Install-Package, and Save-Package fail because they return duplicate copies of each version.

jianyunt commented 6 years ago

@jeopal want does "40 versions of a NuGet" mean?

zarenner commented 6 years ago

More specifically:

NuGetProvider expects a server to implement $top/$skip on the FindPackagesById API. When a server does not, and the number of package versions matches some multiples of the $top page size, such as 40 or 160 (I'm not sure why 80 and 120 didn't repro for me), NuGetProvider performs multiple additional calls with $top=40, and $skip up to 160. Presumably it's looking for another page since the number of results it got back is exactly the page size. The server returns the exact same results (all of them) each time, and the NuGetProvider counts them as duplicate entries.

VSTS Package Management is an example of a server that does not support $top/$skip on FindPackagesById today. It's arguable that the primary bug here is on VSTS for not supporting top/skip, but this was somewhat intentional by VSTS due to performance/scale concerns on feeds with many package versions. That is, VSTS is highly optimized to be able to return all versions at once (e.g. for the v3 flat package index api), so supporting clients that require using extremely low page sizes (40) on feeds with hundreds or thousands of versions is highly detrimental.

I haven't looked at the NuGetProvider code so I can't comment in detail, but some possible fixes on the NuGetProvider side here would be to:

  1. Ignore duplicate versions returned by the server
  2. Understand that when the exact same result set is returned twice in a row, the server does not support paging. 1 is still necessary as the number of versions could have changed between calls.
  3. Not use FindPackagesById() for Install-Package at least, as there exists the more appropriate V2 Packages(Id, Version) API for that. Doesn't fix Find-Package.
  4. Support the NuGet v3 protocol. Doesn't fix V2 users, but there are few reasons (other than NuGetProvider support) why anyone should be using V2 nowaways AFAIK.