-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
40 NuGet bug #30
Comments
@jeopal want does "40 versions of a NuGet" mean? |
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:
|
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.
The text was updated successfully, but these errors were encountered: