We've finally tracked down what was causing this issue. We had two feeds configured that both had two connectors that connected back to the same ProGet server on different feeds. Turns out that this causes a very high request queue on the ProGet server, which in turn caused timeouts and eventually errors during package restore. I've now created a separate web application in IIS hosting the same ProGet folder but running on a different port and configured those two feeds to connect to the other port. This seems to alleviate the problem for now. Would be nice though if this was supported by ProGet itself. I've seen many artifact repositories that support such a feature where sort of virtualized feeds can be created by combining other feeds.

Most definitely; it's a must-have as we transition from a "private NuGet server" to a "private repository manager". I suppose we should explicitly list it under "New repository formats". I'll add a +1 to our (internal) tracker!

All fixed and I finally realized what I was doing wrong the admin password, need to learn where my uppercase characters go in passwords! Thanks, Jon

Hello. What we noticed is that when we receive this error if we delete the nuget package in the feed and then reload it the problem disappear. We still have a legacy feed. Do you think that info could be relevant?

Thanks for the report; in this case, the correct behavior is to not display the log-in form at all when Integrated Authentication is enabled, and instead give an error page indicating no access. I've logged this PG-435

Ah; well, that would explain it :) Your PDB files contain no links to source files, which VS and ProGet are unable o index/locate them. This means you'll need to adjust your complication process to incluse them. A quick search surfaced this article, which may be of assistance: Correctly Creating Native C++ Release Build PDBs. Please do post an update if you find the issue/setting in your project/build file that prevented this from happening.

Actually, one more comment re: this. It appears that the package ID is synonymous with its name. I thought there was a separate ID value. When I grabbed all packages and versions and tried to serialize in PowerShell, it failed due to the size of the content, so it was good to discover that I can query for the specific package name/ID.

Hi, Same question here: http://inedo.com/support/questions/3738. The git repo itself is worth caching for enterprise needs. Actually our developers checkin in the bower_components directory into their git repos, because of the "fear" that the public git repo is getting unavailable. As I can see, https://www.npmjs.com/package/private-bower has this feature. Regards Marco

If you don't specify the symbols option, but include everything in a src directory, then it will work. Keep in mind a NuGet package is just a zip file, so if you're having trouble using nuget.exe with nuspec files and native packages, then you might find it easier to workaround by creating the zip file. Just remember to follow the conventions.

Well, the NuGet API version is totally unrelated; and regarding the v3 API, it's still not stable/public yet, but they are planning a stable/public API at some point in the future (no ETA). Regarding SemVer v2 support for NuGet packages/feeds, tut The NuGet team reports they may support it in v3.5 or v3.6; if/when that happens, we'll add support for it in ProGet's NuGet feed.

We do same in our company. I download Proget from here http://inedo.com/proget/versions and the free verion option is available.

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.

ProGet can host a Bower repo, but a Bower repo is really nothing more than a name/url mapping that points to a Git repo. The packages themselves remain stored in a Git repo. To proxy everything, you'd need to set up a local Git repository and change the ProGet package URL for that package to refer to the local copy.

Good to know as well on this side. Now I know how not to have configuration errors drive me nuts. Now I just have to figure out how I'm going to do this ... Looks like my network will need two ProGet servers ...

For the database, that should work fine. If you have packages stored on the local filesystem of the server, they'll have to be migrated over and kept in the same structure, otherwise the feed storage paths would have to be updated. If the database PackagesRootPath is configured to a UNC path or mapped drive, then as long as that path is accessible from the new server you should be good to go.

On version 5.1.17 this setting is called Web.BaseUrl

Hi Tod, sorry my falled your workaround is working thx

This issue has been resolved in ProGet 3.8.1.

Please see ProGet Features By Edition for more information.