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.

Thanks for the investigation- we'll see if we can get this configurable in the next release, and possibly look into seeing if we can avoid clobbering web.config on upgrades.

We need to add that.. but to back-up ProGet, you just need to Back-up the Database and the Packages directory (the path is listed on each feed, and is in the All Settings under Admin). Then restore the database, and the files on a new server.

Yes - that worked for me. Thank you.

Sorry yes, I meant ProGet (though the implementations are actually the same :)) Anyway, the way that it's currently implemented does require the machine to be a part of the domain. We are aware that this is not ideal and will likely change the way LDAP is queried to make more settings configurable in a future version.

Yes, http://localhost:81/bower/bower/packages/croc.webClient returns a good json: {"name":"croc.webClient","url":"http://myrepo/webclient-dist.git","hits":0}

Regarding the first error – that sort of thing should only happen if the connector returns invalid data. What is the URL of the bower connector? For the registration, it looks like it’s just an HTTP 401. See this article for info about Bower & authentication in ProGet: http://inedo.com/support/kb/1095/introducing-bower-support-for-proget