This sounds like it's an issue with your workstation communicating with the server; the 400 indicates a problem with WIndows/NTLM authentication. That's not done by ProGet, but it's handled by IIS/Windows. It could be a whole lot of things, from system clock being off by a few minutes to domain/security issues. Unfortunately there's not a whole lot we can help with, though i'd suggest to search "Windows Auth not working" while including specific messages you're seeing, and try to narrow down form there. Please share what you find, as someone else might come across the same configuration problem.

Although the VS2015 release is around the corner, we don't believe the v3 API will be ready/stable for public consumption yet. There are no currently no API docs, and the codebase is still moving too much to try to guess what will it will be. We reverse engineered what we could with NuGet3RC2, and it seems to use a blend of v2/v3 API calls. Once the API is ready, we will likely use it to implement the "nuget.org cache" feature that's on our roadmap. That said, the NuGet team will need to (and plans to) support the v2 API in both their client and server components for many years to come, so we're in no rush. The v3 API will primarily offer performance improvements for reaching NuGet.org, but ProGet users aren't really impacted by performance problems anyway, due to local server caching.

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

Please see: http://inedo.com/support/kb/1021/using-proget-with-nuget-the-visual-studio-extension

VPN will occur at a much lower level than ProGet operations (which is HTTP/IIS), so I suggest you use a tools like Wireshark to dig a little further and see where the problem might be.

Hi Just wondering if this issue was resolved ? Pod

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.

Strange. If you open the Tools->Options->Debugging dialog in Visual Studio, is the "Require source files to exactly match the original version" item checked? If it is not checked, that may cause it to use an old source file in the debugger. As far as I know, the PDB age is part of the symbol file's unique identifier - when Visual Studio asks for symbols, it makes a request to a URL with the PDB GUID and age. I think age normally gets incremented when a project is rebuilt in Visual Studio, though I don't know the rules about this for sure. Since you get the correct symbols/source if you clear out the symbol directory, I'm guessing Visual Studio just isn't making a request to ProGet because it thinks it already has the correct files. The best thing to do in this case is to run Fiddler and capture a trace of both behaviors and see what's different. You can send us a copy of these to support at inedo.com if you want some help troubleshooting.

Just add the feed as per normal and when you want to add or update packages, Visual Studio will pop up a message box that allows you to enter the credentials for the feed when you select "Manage NuGet Packages..." or "Manage NuGet Packages for Solution..."

I know this is a really really old thread but I thought I would share something that we did for our continuous integration builds / deployment process. Every build drop location for each build definition will contain a "Latest" folder in addition to the "versioned" folders that contains the output of each build. At the end of our build template, we perform the standard activity of placing the build artifacts in the versioned dropped location. For SUCCESSFUL builds, we copy the contents of the drop location and update the "Latest" folder. If a build fails for some reason, we leave the contents of the Latest folder alone. Our nightly automated package and deployment processes (for automated integration testing) have been simplified to always pull from the "Latest" folder. They can determine if the folder contains the same version as the last one or if it's been updated.

When iam using USB to unlock build master showing error server is not started How can I solve this problem

Unfortunately that issue PG-119 was moved to a future a release because of the priority of the other issues listed in the release notes: http://inedo.com/proget/release-notes#2.1.3 We will try to get this in 2.1.4.

Thank you, it did solve the problem.

Hello, Would it be possible to ask a follow up question to this... Are you using Visual Studio 2010? I tried to find the setting that you mentioned here, but I can't find it in my Visual Studio 2010 setup, and I am wondering if this is only possible in Visual Studio 2012. Thanks Gary