Get-Package : The remote server returned an error: (404) Not Found.

Jan 19, 2011 at 10:51 PM
Edited Jan 19, 2011 at 11:05 PM

One minute everything is fine and the next this error starts happening.

I've been through several uninstalls and reboots and it's still broken. Is this something else I can delete/uninstall to get this working again?



Using command line:

PM> get-package -source
Get-Package : The remote server returned an error: (404) Not Found.
At line:1 char:12
+ get-package <<<<  -source
    + CategoryInfo          : NotSpecified: (:) [Get-Package], WebException
    + FullyQualifiedErrorId : NuGet.VisualStudio.Cmdlets.GetPackageCmdlet

Fiddler shows this:

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 162
Content-Type: text/html; charset=utf-8
Expires: Wed, 19 Jan 2011 22:47:13 GMT
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Wed, 19 Jan 2011 22:48:13 GMT

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="">here</a>.</h2>



This is the log from the most recent install:

1/19/2011 5:33:59 PM - Microsoft Visual Studio Extension Installer
1/19/2011 5:33:59 PM - -------------------------------------------
1/19/2011 5:33:59 PM - Initializing Install...
1/19/2011 5:33:59 PM - Extension Details...
1/19/2011 5:33:59 PM -     Identifier      : NuPackToolsVsix.Microsoft.67e54e40-0ae3-42c5-a949-fddf5739e7a5
1/19/2011 5:33:59 PM -     Name            : NuGet Package Manager
1/19/2011 5:33:59 PM -     Author          : Microsoft Corporation
1/19/2011 5:33:59 PM -     Version         : 1.0.11220.104
1/19/2011 5:33:59 PM -     Description     : A collection of tools to automate the process of installing, upgrading, configuring, and removing packages from a VS Project.
1/19/2011 5:33:59 PM -     Locale          : en-US
1/19/2011 5:33:59 PM -     MoreInfoURL     :
1/19/2011 5:33:59 PM -     InstalledByMSI  : False
1/19/2011 5:33:59 PM -     MinFramework    : 4.0
1/19/2011 5:33:59 PM -     MaxFramework    : 4.0
1/19/2011 5:33:59 PM -
1/19/2011 5:33:59 PM -     Supported Visual Studio Editions :
1/19/2011 5:33:59 PM -         Version : 10.0
1/19/2011 5:33:59 PM -             Pro
1/19/2011 5:33:59 PM -             VWDExpress
1/19/2011 5:33:59 PM -
1/19/2011 5:33:59 PM -     Supported Isolated Shells :
1/19/2011 5:33:59 PM -
1/19/2011 5:33:59 PM -     References      :
1/19/2011 5:33:59 PM -
1/19/2011 5:33:59 PM - The extension with ID 'NuPackToolsVsix.Microsoft.67e54e40-0ae3-42c5-a949-fddf5739e7a5' is not installed to Microsoft Visual Studio 2010 Ultimate.
1/19/2011 5:34:02 PM - The following target products have been selected...
1/19/2011 5:34:02 PM -     Microsoft Visual Studio 2010 Ultimate
1/19/2011 5:34:02 PM -
1/19/2011 5:34:02 PM - Beginning to install extension to Microsoft Visual Studio 2010 Ultimate...
1/19/2011 5:34:02 PM - Install to Microsoft Visual Studio 2010 Ultimate completed successfully. The extension has been installed to C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.0.11220.104\

Jan 19, 2011 at 10:57 PM

Are you able to access from your browser?

Jan 19, 2011 at 11:03 PM

Yes. I get this:

<service xml:base="">


<collection href="Packages">

<collection href="Screenshots">

Jan 20, 2011 at 2:39 AM

I get the same error. 

My Microsoft official package source points to:

Adding a source to seems like an ok workaround... The All view in the GUI returns an message "The remote server returned an error: (404) Not Found."

Hope that helps

Jan 20, 2011 at 4:02 AM

I grabbed the latest source and it looks like it's faulting in HttpClient.cs line 18-28, when I comment out the HttpRequestCachePolicyPolicy() assignment I can run nuget.exe (see below). If one uses something like:

request.CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);

Then things work as well.

Also, it appears that UserAgent is null, not sure what that's about.

public void InitializeRequest(WebRequest request) {
    var httpRequest = request as HttpWebRequest;
    if (httpRequest != null) {
        httpRequest.UserAgent = UserAgent;
    //request.CachePolicy = new HttpRequestCachePolicy();
    request.UseDefaultCredentials = true;
    if (request.Proxy != null) {
        // If we are going through a proxy then just set the default credentials
        request.Proxy.Credentials = CredentialCache.DefaultCredentials;

Jan 20, 2011 at 4:39 AM

@jgeurts: that's an old feed URL.  Delete your source and the correct one should re-appear (after VS restart).  Should be

Jan 20, 2011 at 4:40 AM

@scgarland - We were pushing some bits to the server earlier today which might have resulted in the 404 you noticed. Are you able to consistently reproduce the 404s even now with the default cache policy?
Turning off client side caching would considerably slow down NuGet and doesn't seem like the right solution. 

@jgeurts - Please update the fwlink to

Jan 20, 2011 at 11:41 AM

Yes, it was consistent and yes no-cache made things intolerably slow. I'll try again later tonight when I'm home with the release code and see if things have changed.

Feb 24, 2011 at 10:45 AM

I have the same issue with v1.1.229.160 (seems to be the latest) . I am using default url: I tried reinstalling NuGet, disabling firewall... still wouldn't work. This is what I see:

PM> Install-Package Castle.Windsor
Install-Package : The package source named 'NuGet official package source []' is either invalid or not available and thus i
s currently unreachable.
At line:1 char:16
+ Install-Package <<<<  Castle.Windsor
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.Cmdlets.InstallPackageCmdlet

Browser returns XML
<service xml:base="" xmlns:atom="" xmlns:app="" xmlns="">
    <collection href="Packages">
    <collection href="Screenshots">
Any ideas?
Feb 24, 2011 at 12:43 PM

Try clearing your IE cache.

Feb 24, 2011 at 1:04 PM

Works for me. Sorry, didn't notice it has been discussed. Thanks!

Mar 16, 2011 at 7:48 PM

I too get this error - I've tried clearing my IE cache to no avail

The package source named 'NuGet official package source []' is either invalid or not available and thus is currently unreachable.

Mar 16, 2011 at 7:53 PM

And you can navigate to that url in your brower?

Mar 16, 2011 at 8:19 PM
Yes - I get the normal result:

  <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
- <service xml:base="" xmlns:atom="" xmlns:app="" xmlns="">
- <workspace>
- <collection href="Packages">
- <collection href="Screenshots">
  </service><var id="yiv1890760885yui-ie-cursor"></var>

Mar 16, 2011 at 9:30 PM

This reminds me of a similar thread we had before. Are you using some sort of proxy which modifies the reponse's Content-Type header?

Mar 16, 2011 at 9:35 PM

I asked the LAN team if there were filewall issues.  They said no, but now I wonder...

Mar 16, 2011 at 9:37 PM

Are you able to see packages outside VS using the 'nuget.exe list' command?

Mar 16, 2011 at 9:54 PM

I don't see nuget.exe in

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\

Do you know what other dir to look in?


Mar 16, 2011 at 10:04 PM

I found the command line exe as a separate codePlex download - and it fails with the same symptoms:

C:\NuGet>nuget list
The package source named 'feed []'
 is either invalid or not available and thus is currently unreachable.

Mar 16, 2011 at 10:09 PM

And if you run Fiddler while doing that, do you see any http requests? If so, please include the logs.

Mar 16, 2011 at 10:20 PM

I added as a source which caused me to start getting this error.  I was able to get a list of packaged when I used nuget.exe list however I would get the 'unreachable' message when I tried in VS2010.  As soon as I removed it started working again in VS.  Hopefully this info can help someone else.  Be sure that all your package sources are valid.

Mar 16, 2011 at 10:23 PM

>>  added as a source which caused me to start getting this error. - As a source to what - I'm a newbie and need a tad more hand holding

>> And if you run Fiddler while doing that, do you see any http requests? If so, please include the logs - as soon as I figure out what Fiddler is, etc., I'll let you know

Mar 16, 2011 at 10:28 PM

Don't ask why, but everything is working now - I didn't change anything (I like Fiddler BTW)

Mar 17, 2011 at 6:02 PM

It worked this moring too - and then stopped

I'm back to getting "the" error - even outside of VS - i.e.

nuget.exe list yields

C:\NuGet>nuget list
The package source named 'feed []'
 is either invalid or not available and thus is currently unreachable.

Mar 17, 2011 at 6:05 PM

And are you seeing any requests in fiddler?

Mar 17, 2011 at 6:10 PM


I've just noticed THIS correlation: when I have Fiddler running, nuget list works.  As soon as I exit Fiddler, nuget list stops working!!


Mar 17, 2011 at 6:14 PM

Well, problem fix! Just kidding :)

Interesting. Fiddler inserts itself as a proxy, so it can in some cases affect things. But what's puzzling to me is that you're able to make those same requests from IE (without fiddler). What do your proxy settings look like in IE?

Mar 17, 2011 at 6:30 PM

And here we hit a brick wall - my IE proxy setting is contolled by our LAN team - I can't even see the Connections tab in my IE

Mar 31, 2011 at 11:58 AM

I just wanted to add an anecdote that my corp firewall started blocking non-IE7/IE8 UserAgent strings, and at that same time NuGet stopped getting the feed.

I don't expect anyone to be able to fix it, but if anyone else has a stupid IT department, (:P) they might have the same root problem as I do.

Mar 31, 2011 at 5:52 PM


Mar 31, 2011 at 5:55 PM

As a workaround, you can open Fiddler all the time and add a rule to modify the UserAgent dynamically to become IE7/IE8 user agent.  :)

May 11, 2011 at 8:39 PM

For proxy issues

Other solution will be open Fiddler while you are working with visual studio(to use it as credentials sender) 

Add a customize rule adding this line into "OnBeforeRequest" event oSession.oRequest["Proxy-Authorization"] ="Basic CREDENTIALS";

CREDENTIALS =  Base64 encoded proxy credentials

Works for me.

Jun 28, 2011 at 5:35 PM

I had the same problem as dlaub - when using Fiddler it worked fine. When using Wireshark, I couldn't see inside the traffic to [

To keep debugging it, I changed the source to point directly at Everything worked fine as soon as I did that.