Thank you for the cache tip. I've included -NoCache modifier to a command, and ProGet asked me about credentials.

Hi Dean Restarting the ProGet service solved the problem. Thanks!

It seems to be more stable now, or I can at least see the NuGet page on ProGet. Thanks.

Unfortunately not, but this would be a great place to post it if you are able to get it working! :) But before you do that, check under Advanced Settings to see if modifying the Base Odata URL field will solve the problem you're looking for.

I don't think you're doing anything wrong, but based on this, and your previous error... it sounds like you've got some server/network oddities. That could be any one of a THOUSAND things, but it's definitely not ProGet nor the NuGet clients. So, I'd suggest to put some wireshark or fiddler monitoring in between to see exactly what's happening, where they are coming from, and what the actual responses are.

This should be fixed in v4.5.7 (select NuGet or Chocolatey feed as the first option, and you can change the dropdown afterward). Note, we are considering deprecating the Deploy functionality in the next major version, so if you're looking to get started with deployment you should use BuildMaster instead.

So upon doing a fiddler trace and seeing nothing coming through when I used nuget.exe against our internal repo, I tried it against nuget.org and lo and behold that failed too. It turns out for prior things I had HTTP_PROXY and HTTPS_PROXY environment variables set and nuget.exe didn't like it. This carried over to Visual Studio as well. After removing those variables everything started working again. So, sorry this wasn't ProGet at all (thankfully).

Thanks for letting us know. At some point, we switched to doing connector searches in parallel, so the ordering was no longer consistent for identical packages. It seems to be an easy fix though, so it should be working again in 3.5.6, due out this week.

Thanks Alana. I upgraded to Proget v3.5.6 and updated the timeout period for the nuget feed source to 30s. Now I am no longer getting that issue but I am getting a different one. I logged it as a separate question: http://inedo.com/support/questions/2969

That worked! Definitely a big work around. We additionally had to set the AppPool for the new site to Classic and disable Forms Auth in the bindings.

Hi Dean, I ruled out the proxy since I know I'm getting to the server; I can see it in my IIS logs. What I did notice, is that when I tried to load the package from FeedB into FeedA again, the user the ProGet web app was using to authenticate was DOMAIN\MACHINENAME$ (e.g., NETWORK SERVICE). This account didn't have any rights to access ProGet, so the attempt was failing. My ProGet instance is hosted in IIS and the app pool was running using the application pool ID, so I first tried allowing DOMAIN\MACHINENAME$ access to the feed, but ProGet ignored that principal (I'm guessing you don't allow computer accounts to be added from AD). Next, since I have multiple service accounts lying around, I made the following configuration changes: Granted access to the service account to view FeedB in ProGet's Privileges & Roles Granted the service account access to the ProGet database, and put the user in the ProGetUser_Role role Changed the app pool of the site that the ProGet web app runs under to use the service account credentials Added my service account to the IIS_IUSRS group When I tried loading the package again, it worked correctly. So, the root cause here was that when ProGet is hosted in IIS using a built-in account that translates to DOMAIN\MACHINENAME$, you have to do some additional configuration to grant ProGet access to itself. Although this solved the problem, it would be handy to allow the specification of built-in accounts like BUILTIN\NETWORK SERVICE, or use the computer principal from AD such as DOMAIN\MACHINENAME$ when assigning privileges. Thanks!

You can disable the View privileges from Anonymous user, otherwise you'll have to upgrade to the Enterprise edition (a free trial is available) for more specific, feed-level privileges,

This is related to the timeout question, so I've posted the answer there -- http://inedo.com/support/questions/2915#inline-post-2936

It looks like the timeout box is not being rendered for some reason. We'll be releasing an update this week for ProGet which will include a fix for that. For now, it is possible to set the timeout either directly in the database or using the API. If you have access to the SQL instance, probably the easiest thing to do is change the Timeout_Period value for the connector (it's in seconds). You can get the connector ID by looking at the URL for an edit connector link. After setting it, you'll probably need to restart the web site by going to the All Settings page and just clicking Save. Sorry about this- we haven't needed to change the timeout period for a while. As far as the poor performance goes, I imagine nuget.org simply is not optimizing anymore for the types of queries that our connector filters are using. If there's nothing simple they can do on their end, we'll figure something out, but hopefully it's just a temporary issue with them.

Hi Keith, ProGet is pre-configured with a Connector to NuGet.org -- just go to Admin > Manage Feeds, and then delete the connector.

Thanks, I'll wait until the fix is released. It's not a blocking issue for me.

The discussion for this question is here: http://stackoverflow.com/questions/29254068

I had mistakenly stopped the ProGet service after I switched to IIS hosting mode, so that caused the problem.

All dependency resolution is handled by the NuGet.exe client, here's how you do it: https://docs.nuget.org/create/versioning

Okay, Alana, thanks for your help. We will do just that.