Thanks Dean - that was super helpful :) I resolved this issue by only promoting the symbols package if one existed. Many thanks!

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

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

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.

You may be best asking this on NuGet forums, as this relates to behavior in the nuget.exe client. We do not use "nuget.exe pack" ourselves (instead, we opt to use the proget client tools) as it's more reliable and has defined behaviors.

ProGet works great with NuGet client v3! As far as the "protocol" is concerned (i.e. ODATA vs JSON-LD) the "v3" protocol is intended only for use by nuget.org and nuget client. It's not documented by Microsoft, unstable, and they have no plans to document or support it. Since the "v2" protocol (ODATA) works just fine, we are not going to reverse engineer the "v3" protocol or otherwise use it.

That option unfortunately will not work at this time without significant changes, and it's supposed to be hidden currently. We may remove it in the next version or add the required functionality to get it working in an even later version. The problem with it is that dependencies can now vary based on other factors such as platform, .NET Framework version, etc. As a workaround, enabling caching for the feed and downloading the package from Visual Studio will accomplish essentially the same thing, though.

The story continuous :) Because I set TeamCity to create source packages as well (it's a checkbox called: Include sources and symbols) it was overwriting the packages in ProGet (I have all the PDB and sources in my nuspec files as well). This was causing the issue with the config file being gone, because TeamCity strips those files out for the symbols packages. So... I was doing things twice... Must be user error ;)

Hi Just wondering if this issue was resolved ? Pod

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

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 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

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.

Do you have any connector filters? If so, try removing those to see if it works. Also, try using the non-SSL URL, i.e. http://www.nuget.org/api/v2 and see if that works. I would also double-check the proxy configuration if you have one set up. If so, see what the message when “Test Proxy Connection” is clicked.

Ah, I see; please note that we do not support v1 feeds (they were already obsolete when we build ProGet in 2012) and we have no intention to. Suggest you push packages from TeamCity to ProGet instead.

Nice read, I just passed this onto a friend who was doing some research on that. And he actually bought me lunch as I found it for him smile Thus let me rephrase that Thanks for lunch! bagkeecdckkdedbb

Just want to confirm that the issue is fixed in ProGet 3.4.7. Thanks!

In short, only push the .symbols package which contains all of the same files in the standard NuGet package, plus the symbols/source. For more info, see: http://inedo.com/support/questions/1409

If the feed is a legacy feed, then the import folder is not used; instead packages can be added directly to their storage location. Assuming it's not a legacy feed: Is there anything in the ProGet error log or package indexing error log? Both are accessible from the admin page. If there's nothing in there to indicate a problem, I would try running the ProGet service interactively to see if there's any relevant non-error logged. Just stop the service, and run: Proget.Service.exe run By default, it scans the directory every 60 seconds, so you should see some info about it running a DropPathMonitorExecuter every so often.