Ah yes, that solved my problem. Thanks!

This was a regression in 4.1.2, but it is fixed now in 4.1.3.

The feedCleanup makes sure the files on disk and metadata files in sync. It'd be fine to run weekly or disable. There are no additional settings available, but we may add something to mitigate this in the future; it's extremely rare, and it's quite complex to handle properly.

Aha! Thank you! I didn't realize the feed wasn't at the root, since normal 'nuget push' and 'nuget install' commands worked with just the root URL as the '-Source' parameter. Only the 'nuget restore' failed.

Hmm, I wonder if it's related to Powershell Execution Policy? I'm not terribly familiar myself, but I know I've had to fiddle with that a bit to get things working... 15 Ways to Bypass the PowerShell Execution Policy

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

The BuildMaster NuGet Extension is a wrapper around the nuget.exe client. So it really depends on the client version you're using and how you've configured it. See InstallPackagesOperation.cs

This is by design. The "Packages" listing page (/packages) lists the packages (and all the versions) stored on the local server, across all feeds. The "Feed" page (/feeds/FeedName) will show the aggregated view of packages on the local and remote servers, collapsing all the various versions into a single version.

This seems to be unrelated; the problem before was that ProGet was not providing a 404 when a package was not found, but instead an empty result. Also, we cannot reproduce this error at all, so it's isolated to yours. As such, please Ask a New Question as not fill this one; and also make sure to provide a stack trace of the 500 error message; this can be found in Admin > Error Logs.

ProGet is the server, so it just hosts your private packages. If you want to push something to a different feed, use the -Source ... argument in the nuget.exe client. Connectors for NuGet are simply a convenience that make it easy to cache nuget.org packages and provide a single endpoint to download them.

Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.

I would use .NET 4.5 with NuGet.exe to be safe.

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

UPDATE: This is a breaking behavior change planned for NuGet 3.4. https://github.com/NuGet/Home/issues/2298 This may not have a large/widespread impact, and it might be difficult for us to fix server side without breaking everything other than NuGet 3.4... so for now our advice is "don't upgrade to 3.4 or don't rely on that behavior". Please update/share if this issue impacts you.

When I trying after remove all connectors, NuGet.exe install command works without any exceptions. :(

Today it's working fine. So definitely a temporary outage on nuget.org.

npm does not support Windows Auth. Unfortunately IIS/ASP.NET does not allow for some things to be Anon, some things to be Windows -- the whole site is one or the other. Best workaround is to create two IIsSites on the site server with different ports. You can point both of them to the same application directory. Note this does not require a separate license because it's considered the same instance, and largely a workaround for the authentication problem.