NuGet - Installing Individual Packages reporting “

Question

When using a local NuGet server, whenever I try to install an individual package from that server, all I get is this error: "The remote server returned an error: (404) Not Found."

The packages are all there in the filesystem and the feed itself sees all the packages appropriately. I can even browse the package directly!

What am I missing?

I did just upgrade from NuGet server 1.4 to 1.5, but I've seen this happen before. Touching the package files used to help, but that does not appear to be the case now.

EDIT: Actually, I hadn't seen that exact error before...I've seen this one, intermittently, that touching the package tended to fix.

Answer 1

I had the same problem, srv 2008 R2. Changed the application pool to Integrated from Classic and all works fine now.

My problem was same as image above. I could go to the site on url

http://localhost:3407/nuget/Packages but not http://localhost:3407/api/v2/package/{package name}/1.0.0.0

Answer 2

I encountered this error while trying to download Signal-R after update Nuget, however it was just that I had not checked the "Allow Nuget to download missing packages during build" option in package manager settings. Once that was that set it all worked fine again.

Answer 3

On Windows Server 2008, I was having the same issue. I switched the Application Pool from "ASP.NET v4.0 Classic" to "ASP.NET v4.0". The install-package command worked fine after the change.

Answer 4

I was having the same issue on Windows Server 2008. Problem was in my own package MyPackage.nupkg that I saved without version. MyPackage was visible in PackageManager but it was getting 404 error on install.

Fix: I saved it with name MyPackage.1.0.0.nupkg (1.0.0 is current version) and problem was fixed.

Answer 5

sigh...

http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx

EDIT: In case the link ever dies...I am hosting my NuGet server in IIS6, which wasn't set up to properly handle extensionless URLs. And since the semantics of downloading individual packages changed from a direct file link to an extensionless route, I started getting 404s. Adding the wildcard mapping described in the article fixed it instantly.

Answer 6

I've been trying to figure this for a couple of hours...

Checked the IIS logs and discovered that URLScan was blocking the route:

GET /Rejected-By-UrlScan ~/api/v2/package/

URLScan doesn't accept any route not starting with '/'. The best I could do was to remove the URLScan from the list of ISAPI filters for the website in the IIS Manager.