Dependencies not working

I am trying to just use the default ProGet feed (has 1 connector to https://nuget.org/api/v2/)

When I run:

nuget.exe install NServiceBus.Interfaces -o "C:\temp\packages" -source "http://localhost:87/nuget/Default"

I get:

Unable to resolve dependency 'NServiceBus (≥ 5.0.0)'

if I run the exact same command with the nugget URL is works fine:

nuget.exe install NServiceBus.Interfaces -o "C:\temp\packages" -source "https://nuget.org/api/v2/"
Attempting to resolve dependency 'NServiceBus (≥ 5.0.0)'.
Installing 'NServiceBus 5.0.0'.
Successfully installed 'NServiceBus 5.0.0'.
Installing 'NServiceBus.Interfaces 5.0.0'.
Successfully installed 'NServiceBus.Interfaces 5.0.0'.

I am starting with clean caches when running (Proget, Nuget and package output are cleaned)
I am using Nuget.exe 2.8.2
I am using Proget 3.1.7 running in IIS (same behavior when running as service)

Product: ProGet
Version: 3.1.7

According to NuGet, "this packages has been deprecated." So, I'm not sure if that's part of the issue. It's entirely possible that this package is queried differently, in some undocumented manner (certainly wouldn't be the first time).

Can you use fiddler to identify which specific HTTP requests is working (at NuGet.org), and which isn't (via ProGet)?

Here is the output hitting nuget.org:

nuget.exe install NServiceBus.Interfaces -o "C:\temp\packages" -source "http://nuget.org/api/v2/" -version 5.0.0 -verbosity detailed

GET http://www.nuget.org/api/v2/Packages(Id='NServiceBus.Interfaces',Version='5.0.0') 
Attempting to resolve dependency 'NServiceBus (ò 5.0.0)'. 
GET http://www.nuget.org/api/v2/FindPackagesById()?id='NServiceBus' 
GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','3.3.3-unstable1' 
GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2472' 
GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2614' 
GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2948' 
GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.3.6' 
GET http://www.nuget.org/api/v2/package/NServiceBus/5.0.0 
GET http://www.nuget.org/api/v2/package/NServiceBus.Interfaces/5.0.0 Installing 'NServiceBus 5.0.0'. 
Successfully installed 'NServiceBus 5.0.0'. 
Installing 'NServiceBus.Interfaces 5.0.0'. 
Successfully installed 'NServiceBus.Interfaces 5.0.0'.

Fiddler trace:

GET http://nuget.org/api/v2/
301 Redirect to http://www.nuget.org/api/v2/

GET http://www.nuget.org/api/v2/
200 OK (application/xml)

GET http://www.nuget.org/api/v2/Packages(Id='NServiceBus.Interfaces',Version='5.0.0')
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/$metadata
200 OK (application/xml)

GET http://www.nuget.org/api/v2/FindPackagesById()?id='NServiceBus'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','3.3.3-unstable1'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2472'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2614'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.0.0-unstable2948'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/FindPackagesById?id='NServiceBus'&$skiptoken='NServiceBus','4.3.6'
200 OK (application/atom+xml)

GET http://www.nuget.org/api/v2/package/NServiceBus/5.0.0
302 Redirect to http://az320820.vo.msecnd.net/packages/nservicebus.5.0.0.nupkg

GET http://www.nuget.org/api/v2/package/NServiceBus.Interfaces/5.0.0
302 Redirect to http://az320820.vo.msecnd.net/packages/nservicebus.interfaces.5.0.0.nupkg

Here is the output hitting my local ProGet:

nuget.exe' install NServiceBus.Interfaces -o "C:\temp\packages" -source "http://dev-mjohnson:87/nuget/Default" -version 5.0.0 -verbosity detailed

Unable to resolve dependency 'NServiceBus (≥ 5.0.0)'.

Here is the Fiddler trace:

GET http://localhost:87/nuget/Default
200 OK (text/xml)

GET http://localhost:87/nuget/Default/Packages(Id='NServiceBus.Interfaces',Version='5.0.0')
200 OK (application/atom+xml)

GET http://localhost:87/nuget/Default/$metadata
200 OK (text/xml)

GET http://localhost:87/nuget/Default/Packages()?$filter=tolower(Id)%20eq%20'nservicebus'&$orderby=Id
200 OK (application/atom+xml)

Thank you for the report. The problem stems from the fact that NuGet limits the results of the FindPackagesById() method to 100 package versions, followed by a "next" link with the next package version to start requesting from instead of simply starting at version 5.0.0 and getting the next 100 from there (which there is only 1 at this time of course). We did not realize that it did this, so ProGet does not add the <link rel="next"... and the client cannot find version 5.0.0. We will definitely add support for this in an upcoming version (not today's v3.2 release, but soon thereafter).

Worth noting, local ProGet server packages are not limited to this 100 count, so you can work around this problem by pulling the package to ProGet from the connector, then it should work when you retry installation.

Great, thank you for the information, response and workaround. I look forward to getting ProGet into our development environment.

ProGet v4.0.8 (Build 1) still exhibits this limiting behaviour when trying to resolve EasyNetQ packages. EasyNetQ is active and currently has 350 packages in the NuGet repository.
Is there still no fix?

Unfortunately this is not at all trivial to implement. It has a fairly small impact with a relatively easy work-around, so for now we are going to wait until the "offline index of NuGet.org" is scheduled as a feature, and implement as part of that,.

That's unfortunate, but understood. Thank you for your timely response.
However, I certainly wouldn't classify the workaround as easy with an actively released package such as EasyNetQ. Am I right in assuming the workaround would require manually monitoring for new versions on NuGet and pulling the new packages to ProGet whenever a new version is released? If so, that is quite an administrative overhead.
I'm sure there are other packages on NuGet which have crossed the 100 releases boundary (or are nearing it), so this is probably not an isolated case.