404 Not Found from Remote Server

Feb 17, 2011 at 12:49 AM

I created a remote server local to my company following the instructions in the documentation.  I had to change the url to be ../odata/v1 to even get the packages to show up in the feed.  However if try to install one of the packages that is visible on my remote server, I get a 404 error.  Any ideas?

Feb 17, 2011 at 6:02 AM

I'm not sure if I'm even on the right track or not, but debugging the server, the method call PackageUtility.GetPackageUrl(package.Id, package.Version, operationContext.AbsoluteServiceUri) on line 45 of Package.svc.cs the value returned is http://localhost:14357/Packages/log4net.1.2.10.nupkg when the REAL location on my server is http://localhost:14357/Packages/log4net.1.2.10/log4net.1.2.10.nupkg however changing the value in the code to correctly reflect the download path for the .nupkg file doesn't seem to solve 404 error when trying to do an install.

Feb 17, 2011 at 6:34 AM

Can you tell me how you set up your NuGet.Server (exact repro steps)?

Feb 17, 2011 at 3:24 PM

I set two up, I'll list both


Server 1

Downloaded source.

Built Solution

Published Server project

Deployed to IIS 7

Set url in package manager to http://myserver/odata/v1

Issued get-package -remote command via nuget console, it returned the list of packages

Issued install-package log4net, (which was in my repository), server returned a 404.


Server 2

Downloaded source

set Server project as default startup project

started server in debug

set url in package manager to http://localhost:<port>/odata/v1

Issued get-package -remote command via nuget console, it returned the list of packages

Issued install-package log4net, (which was in my repository), server returned a 404.

observed via debug that the url it was trying to get package from was http://localhost:14357/Packages/log4net.1.2.10.nupkg when the real url should be http://localhost:14357/Packages/log4net.1.2.10/log4net.1.2.10.nupkg


One thing of note, the way I put the packages in the "Packages" directory was I went to one of my projects where I had used NuGet, copied all the packages out of there, and then dumped them in the packages directory on the server.


Feb 17, 2011 at 3:48 PM

If I change line 14 in PackageUtility.cs from


return VirtualPathUtility.ToAbsolute("~/Packages/" + GetPackageFileName(id, version));


return VirtualPathUtility.ToAbsolute("~/Packages/" + id + "." + version + "/" + GetPackageFileName(id, version));


It now works.  Did I do something wrong in placing the files in the packages folder on the server?

Feb 17, 2011 at 4:44 PM

The above fix only works for my dev instance, if I try to deploy it to IIS I still get the 404, but at least my dev version works.  I'm not really sure what is going on.

Feb 17, 2011 at 4:50 PM

Ok I got it working on my IIS server now, the setting I was missing in IIS was setting the .nupkg extention mime type to application/zip, it still did require that change to the code I mentioned above.

Feb 17, 2011 at 5:42 PM

Ok after commenting on an issue that relates to this, the author informed me that he thought you could just put the .nupkg file in the Packages directory without the lib folder or anything else, after testing that works, so it appears that there rather than there being a code issue, it was a combination of not understanding how to structure the packages on the server, and an IIS setting, setting the correct mime type.

Feb 23, 2011 at 11:55 PM
Edited Feb 23, 2011 at 11:58 PM

What ended up being the full fix?

I keep getting 404's from the IIS server, even though I can go http://server/NuGet(dir it's at)/Packages/FooBar1.0.nupkg, where the Mime type has it set as a compressed file.

In the packages folder of the app, its only file is the nupkg file spit out by the packager, unaltered.

In the package install dialog, it lists all of the info but doesn't install.

More infuriating is I got it working on my local IIS server(not a dev server) and migrated the app folder to the new server, where it does not work at all.

Feb 28, 2011 at 7:01 PM

This is still an issue for me.  All of my packages are flat and exist in /Packages.  Like @clutchdude, if I navigate to http://server/MyVirtualDirectory/Packages/FooBar.1.0.nupkg, I am able to download the zip file.  

Feb 28, 2011 at 7:02 PM

What ended up working for me was adding the .nupkg extension to the mime types in IIS as application/zip

Feb 28, 2011 at 7:16 PM

I did that and still I get 404 errors for my packages.. any other thoughts? 

Feb 28, 2011 at 7:20 PM

Only other thing I did, was made sure that the user that IIS is using as part of the web application had full rights to the directory where my packages were installed.

Feb 28, 2011 at 8:21 PM

The app pool that is setup for that virtual directory has full permissions to the directory.  Is there verbose logging or anything I can turn on for that application?  Looking at the IIS log doesn't really shed any light on the situation.

Mar 2, 2011 at 3:40 PM

Anyone from the project care to chime in on this?  It would be nice to use the server component. 

Mar 2, 2011 at 7:32 PM

Probably best to open a bug to track this is there isn't one already.

Mar 3, 2011 at 7:09 PM

Tried everything suggested here, keep getting 404 :( HTTP debugger doesn't show any error response codes.

Mar 3, 2011 at 7:24 PM

Try clearing your IE cache

Mar 3, 2011 at 7:26 PM

I created an issue for this: http://nuget.codeplex.com/workitem/763

Mar 4, 2011 at 11:10 AM

The project is useless anyway. I was looking for a maven alternative in the .NET world, and nuget is way far from it.

From what I understood you have to commit your BINARIES  into subversion repository, which is not acceptable. You can as well have a  file share and copy 3rdparty libs into your solution lib folder manually. What's nuget for anyway?

I couldn't find  out how to get a project from subversion having only the main source + nuget config files :(

Mar 4, 2011 at 4:08 PM

Nice work on hijacking this thread... setup your own thread and I'll point you here: http://biasecurities.com/blog/2010/creating-nuget-packages-with-teamcity/.  The point is that you don't store binaries anywhere...you just have your continuous integration server build/distribute the nuget packages when it builds your libraries

Mar 4, 2011 at 4:17 PM

Say you publish nuget package of library1. There is another team's solution1 using library1 referenced via nuget company's repository. How do you update solution1's binary library1 in CI server without writing huge msbuild scripts?

Mar 4, 2011 at 4:18 PM

It started working eventually after I came back in an hour. Didn't do anything, could be IE cache indeed.

Mar 4, 2011 at 4:18 PM
Edited Mar 4, 2011 at 4:19 PM

How does IE cache affect IIS?

Mar 4, 2011 at 4:22 PM
cgibbons24 wrote:

How does IE cache affect IIS?

It doesn't, but it may affect client. According to http sniffer client doesn't event do http request when it dies with error 404.

Mar 4, 2011 at 4:26 PM

@jgeurts Sorry you're running into this. We need more information about your IIS setup. Are you using IIS 7 in integrated mode? IIS 7 is pretty locked down out of the box. Make sure IIS 7 is configured to serve static files.

If you go to Add/Remove Programs (on Win 7 -> Start | Programs and Features), click on "Turn Windows features on or off", then navigate to Internet Information Services, World Wide Web Services, Common HTTP Features, and make sure "Static Content" is checked.

Mar 4, 2011 at 4:36 PM

@haacked Thanks for the help.  My virtual directory is setup to use .net 4.0.30319 integrated.  I also verified that Static Content is installed for the web server.  The box is a 2008R2 instance running IIS 7.5, if that helps.  If there is anything else I can provide, let me know

Mar 4, 2011 at 6:05 PM

As much information as you’re willing to share. J

Screenshots of IIS configuration. Show the directory structure in IIS and in Windows Explorer.

Mar 4, 2011 at 6:14 PM

Did you clear the IE cache? If you can get it working in the browser but not the nuget client it's most likely if not definitely the IE cache.

Mar 4, 2011 at 6:15 PM

I think the issue is it’s not working in the browser or client. I haven’t had a chance to ensure you’re using the correct URLs etc.

Mar 4, 2011 at 6:23 PM

It's working now - Looks like was a cache issue.  After waiting a few days and just trying now, the packages install as expected.  Thanks for your help with this guys!

Mar 4, 2011 at 8:45 PM

Oh great! Can we close the issue you opened then?

Mar 4, 2011 at 8:58 PM

Yep, thanks again for the help

Mar 10, 2011 at 5:01 PM

Had the same issue. No suggested solution worked for me. I fixed it by simply addressing the service directly:

http://localhost/nuget/odata/v1/ => http://localhost/nuget/dataservices/packages.svc

Apparently, there is a routing or mapping issue. On production, I have Win Server 2008 Std + IIS 7.0. What is interesting, the same compiled project deployed on my dev PC works fine (Win 7 + IIS 7.5).

Apr 1, 2011 at 7:15 PM

I have the same issue as oleksiimdr.  IIS 7.5, Win Server 2008.  http://server/nuget/Packages returns 404, http://server/dataservices/packages.svc works just fine.

Sep 2, 2011 at 8:06 AM
Edited Sep 2, 2011 at 8:07 AM

If you're getting a 404 after upgrading and you're running IIS6 you probably have to set a wildcard mapping, see my blog post for more info: http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx

Feb 5, 2013 at 12:49 PM
the problem for me was I created a WebSite project not a precompiled ASP .NET project, when I deployed I got the 404 error. once I switched to the correct project type it worked as expected
Feb 7, 2013 at 9:06 AM
I keep getting this error as well, at least l'm not the only one struggling with this. It can be so annoying when you get these 404's

Keep fit with the various weights for sale
Oct 11, 2013 at 7:22 PM
oleksiimdr wrote:
Had the same issue. No suggested solution worked for me. I fixed it by simply addressing the service directly: http://localhost/nuget/odata/v1/ => http://localhost/nuget/dataservices/packages.svc Apparently, there is a routing or mapping issue. On production, I have Win Server 2008 Std + IIS 7.0. What is interesting, the same compiled project deployed on my dev PC works fine (Win 7 + IIS 7.5).
Thank you oleksiimdr. This resolved it for me.
Oct 31, 2013 at 6:08 PM
2013 and still an issue... in my case the fanciness that is [assembly: WebActivatorEx.PreApplicationStartMethod(typeof(ASP.NuGetRoutes), "Start")] process activation was not working at application startup and therefore not registering the routes. A viable work around is to add a Global.asax to your project and add NuGetRoutes.Start.
    void Application_Start(object sender, EventArgs e)