No problem! Now for a barrage of questions... Where is the 503 response coming from, ProGet or the proxy server? Is there an error message in addition to the status code? What do you mean by "use the ProGet feed", does that mean browsing the ProGet web application (i.e. feed overview page), or accessing packages via nuget.exe/Visual Studio? And does it work as expected if you access ProGet over HTTPS?

I've read that NuGet's architecture is being redesigned for version 3.0, which should also improve the performance. http://blog.nuget.org/20150608/nuget-server-status.html http://blog.nuget.org/20150601/nuget-3.0-rc2.html

I see. Thanks for the feedback - I didn't think about retention but that is a very good point. Retention itself is also a relatively new feature for ProGet, and we are still evaluating whether it ought to be included in the free edition in some form. Regarding feed-specific override paths, we probably will add this in a future release, but I can't give you a specific version as yet.

The INEDOPROGETSVC service is used by ProGet to perform background tasks (indexing, cleanup, etc) and is required to run ProGet. The only options (right now anyway) to install the ProGet web application are: IIS-hosted Integrated web server (this is essentially a 2nd Windows service) Linux via Docker (currently v4.0 in beta)

To find the connector, go to Admin gear > Manage Feeds > Edit Feed (pencil icon), and that will have the list of connectors. For the error itself, try some of these recommendations: http://stackoverflow.com/a/703285

Integrated, so it uses the account hosting the web application to query.

You can look in the Web.config file in the ProGet Service directory to see what connection string it is currently using to connect to the database. If you installed everything with default settings, this will be using integrated authentication, so it's connecting using whatever account the ProGet Service is running as. Outside of this, whoever installed/updated ProGet last would have also needed to have access for integrated auth.

This isn't currently exposed in the UI, but you can run this SQL query against ProGet's database to get a list of cached packages in a NuGet feed: SELECT * FROM [NuGetPackages_Extended] WHERE [Cached_Indicator] = 'Y' AND [Feed_Name] = 'MyFeedName'

Hi Mark, We just sent you an email with a stop-gap license. Please let us know if you don't get it.

That's actually supposed to be cached, but due to a bug it looks like it's only cached if there is not a timeout when trying to download the news. We'll get that fixed in a maintenance release; thanks for letting us know!

This is not a known problem on the server-side of ProGet, but instead a problem on the client; that "Stream" is referring to something opened on the client, and closed on the client. We've also seen similar behavior with some 2.8.x versions of NuGet.exe, and perhaps OD shares some of that code?

Sorry about the broken link! That article has be updated and that link should now redirect to the correct page: http://inedo.com/support/documentation/proget/feeds/nuget/visual-studio-extension

Now that the current version of Visual Studio seems to respect authentication challenges, we are adding support for this. The tracking issue is here: PG-1273

Thanks; we've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however.

This was fixed in ProGet v3.6.2, thank you again for the report.

Most definitely not. Unfortunately, we have no idea when NuGet v3 will come out, nor do we know when/if there will be API docs availalble (or a stable codebase to reverse engineer the API). Based on the various iterations of the v3 API that have been published in preview/beta, we have little confidence that it will solve the performace problems that ProGet users experience with connected/remote packages; so, on the ProGet Roadmap, we plan on solving that by creating a full index of nuget.org. That said, the NuGet team will need to support v2 for several years to come, so we're in no rush. Moreover, We have a plan that http://inedo.com/support/questions/3130

That sound like a good solution!

As long as the Global Catalog can search the other forest it should work, if there is a restriction on that, then it will not find the user. By default however, it uses the Forest.GetCurrentForest() to determine which GC to query. We are now planning to make some improvements to the way authentication works as it is slowly becoming the #1 requested feature/improvement.

See: http://inedo.com/support/questions/3090

Thank you very much guys for pushing this feature to the last release. I've upgraded our server today, turned the option on, and it works great. Cheers.