Getting package verification errors


I'm getting package verification errors for some packages in the RTM OData feed with current RTM build from source (a0686ad4c483). The same package I saw this error with yesterday (Antlr) is working today, and a new one is now having the error (Ninject).

The error:
Failed to download package correctly. The contents of the package could not be verified.

Also, see attached screen capture.

file attachments

Closed Mar 22, 2011 at 10:04 PM by Haacked
This is fixed in 1.2


Haacked wrote Dec 6, 2010 at 10:18 PM

Please investigate. We need to understand if this is a core issue or a gallery issue.

drewmiller wrote Dec 8, 2010 at 7:42 PM

Could not repro. Appears to have been a Gallery Server issue and not a client issue. We should open it if we encounter it again.

** Closed by drewmiller 12/08/2010 11:42AM

shawty wrote Dec 13, 2010 at 9:22 PM

Dec 13th, this has happened for me while following scott-gu's EF5 blog post.

At the very first hurdle : Install-Package EFCodeFirst

Results in the following

Install-Package : Failed to download package correctly. The contents of the package could not be verified.
At line:1 char:16
  • Install-Package <<<< EFCodeFirst
    • CategoryInfo : NotSpecified: (:) [Install-Package], InvalidDataException
    • FullyQualifiedErrorId : NuGet.VisualStudio.Cmdlets.InstallPackageCmdlet



shawty wrote Dec 13, 2010 at 9:27 PM

Just tried it the GUI way too, and got the following (See attached screen shot)

mrdecav wrote Jan 8, 2011 at 12:35 AM

We have been experiencing this issue with the v1.0 as well.

The issue should be reopened, as the gallery seems to have an issue when you update a preexisting package to a new version. Occasionally, the hash being returned from the server seems not to match the packages actual hashcode.

Graffen wrote Feb 25, 2011 at 1:34 PM

We're seeing the same thing on some of our developer machines when trying to update or install packages fed from our local NuGet server.
On my machine everything works like a charm but several of my colleagues can't update or install packages from the in-house feed. They all see the same error message as posted in this thread.

SteveRobbins wrote Mar 10, 2011 at 7:53 AM

I'm getting this error this morning when trying to install Nancy. I'd previously had an older version, removed it, and when I try and re-add:

PM> install-package Nancy.Hosting.Aspnet
'Nancy (≥ 0.4.0)' not installed. Attempting to retrieve dependency from source...
Install-Package : Failed to download package correctly. The contents of the package could not be verified.
At line:1 char:16
  • install-package <<<< Nancy.Hosting.Aspnet
    • CategoryInfo : NotSpecified: (:) [Install-Package], InvalidDataException
    • FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.Cmdlets.InstallPackageCmdlet
Running NuGet on 2010SP1.

clevinas wrote Mar 12, 2011 at 1:40 PM

I hit this bug yesterday with NuGet, debugged it, and here is what causes it, and how to fix it. I know the workitem reads 'closed', but the bug is still alive, I'm afraid.

I created a package for my library 'postal.js' and uploaded it to NuGet's website. Went to VS to check that it installs well, but it failed because I had made an error in the file structure of the package. The download was successful though, creating the files in the packages folder of the project.

I fixed the file structure, repackaged, and resubmitted the new package to NuGet's website (deleted the previous one, and replaced it with the fixed one, using the 'same package name' and 'same version number' as before). When I tried to install the fixed version, I got the verification error, and the package didn't download.

The bug occurs because of a problem with HttpClient's cache. When I first created the faulty package, it was downloaded, and cached in IE's Temporary Internet Files. When I then went to install the new package, NuGet found the old one cached, and used it to compute the hash, naturally finding that it did not match the expected one.

General fix: Clear IE's cache, or navigate to 'Temporary Internet Files' and delete the old cached package, on the computer where the bug is happening.

NuGet fix: Patch the file Core\Utility\HttpClient.cs to never use cache.
request.CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);
Or better yet, if the verification fails in Core\Utility\PackageDownload.cs
if (!_hashProvider.VerifyHash(streamBytes, packageHash)) {
    throw new InvalidDataException(NuGetResources.PackageContentsVerifyError);
before throwing the exception, attempt to call GetResponseStream one more time, but this time passing to _httpClient.InitializeRequest() an extra parameter HttpRequestCacheLevel.NoCacheNoStore to be used by the the function to bring a fresh new copy from store. If this one fails then do throw the exception.

Hope this helps,

drewmiller wrote Mar 12, 2011 at 5:47 PM

Re-opening for triage to consider clevinas' comment.

jredekop wrote Mar 16, 2011 at 12:27 AM

I was able to resolve this by:
-setting the Http Response Headers to Expire Web Content Immediately (http://screencast.com/t/ocYzwU2eQ)
-closing vs & clearing cache in IE

At least that works for today...

dfowler wrote Mar 16, 2011 at 8:59 AM

We no longer aggressively cache using the WinInet cache so this shouldn't be a big issue anymore.

mausch wrote Mar 22, 2011 at 7:52 PM

I just got this error. I first submitted a package (FsSql) created with NuGet 1.2. When I realized 1.2 wasn't released yet, I rebuilt the package with 1.1, removed the original, and pushed the new one. Now it throws this error when trying to install it. Cleared IE cache, then it worked.

michaelstum wrote Apr 25, 2011 at 11:34 PM

Still getting this issue, even in 1.3.20419.9007

MattXPO wrote May 7, 2011 at 8:15 PM

I'm still getting this issue as well.

dfowler wrote May 9, 2011 at 3:36 AM

Are you hosting a custom server or do you see this with the main feed?

stejcz wrote Sep 2, 2011 at 9:35 AM

Same problem here with custom nuget feed.

PVV wrote Sep 30, 2011 at 6:59 AM

I had this issue with my Custom Nuget feed aswell. My solution was to restart the NuGetFeed site, seems like he was responsable for caching

ozziepeeps wrote Dec 10, 2013 at 11:09 PM

Just started getting this issue today using 2.7.2 on client and server.