39

Closed

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

description

Trying to install a custom package from a custom repository produces the message:
"Failed to download package correctly. The contents of the package could not be verified"

Steps to reproduce:
I'm not quite sure.... I have to reproduce it again in another solution. BUT, I think it is:
1) Add a custom package source
2) Try to add a custom package from the new source to your project
Closed Jan 13, 2012 at 12:46 AM by JeffHandley
Closing as the customer reported that upgrading fixed the problem.

comments

dfowler wrote Jan 24, 2011 at 7:02 PM

Why server based source were you going against?

jesschadwick wrote Jan 24, 2011 at 7:33 PM

I set up a custom server using the Server project from the latest changeset (as of about 10 AM EST this morning), as per the "Hosting Your Own NuGet Feeds" documentation page.

Also, the whole add/remove source thing seems to be a red herring - looks like none of my feeds from the server work any longer... This is probably another issue entirely. (Updating the initial issue to reflect this)

Haacked wrote Jan 25, 2011 at 10:27 PM

We don't actually ship the server publicly. However we do want to maintain it and make sure it works. If you can help us figure it out, we'd love to accept patches. Otherwise we'll fix it when I find time to do it. Sorry for the issue.

jesschadwick wrote Jan 26, 2011 at 12:01 AM

I'd love to help - I'll see what I can do.

clevinas wrote Mar 12, 2011 at 1:46 PM

For a solution, please see my comment to workitem 426 at http://nuget.codeplex.com/workitem/426
Claudio.

lordeagle2000 wrote Apr 21, 2011 at 7:03 PM

Having the same issue with a private hosted server (as demonstrated by Haacked @ MIX).

If I add a local folder as repository, it works just fine. However when pointing to a URL of my private server I get the verification error:

Install-Package : Failed to download package correctly. The contents of the package could not be verified.
At line:1 char:16
  • Install-Package <<<< My.TestPackage
    • CategoryInfo : NotSpecified: (:) [Install-Package], InvalidDataException
    • FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

RobinM wrote Apr 27, 2011 at 12:19 PM

We get this issue intermittently with our private server, using v1.2 and v1.3 clients. Watching via Fiddler2, the download succeeds. Downloading the package manually and installing from a local repository succeeds.

dlpowell wrote Apr 27, 2011 at 1:06 PM

I see this using NuGet.exe too. It seems that if a package has a "\lib\net4" folder (as in is the case with Rx-Core.1.0.2856.0) or "\lib\4.0" folder (as is the case with RavenDB-1.0.0.322) then NuGet.exe 1.3.20425.372 says it can't verify the package (although NuGet Package Explorer and the VS addin don't seem to have a problem).

I verified this with one of our own private packages which had a "net4" folder. Changing it to "net40" allowed NuGet to install the package.

dlpowell wrote Apr 27, 2011 at 2:16 PM

On closer inspection, this it seems that changing the folder under lib was a red herring. Merely updating the package's last write time (on the server side) allowed NuGet.exe to verify and install the package.

RobinM wrote Apr 27, 2011 at 3:10 PM

Something is being cached somewhere still it seems but I've found a workaround as suggested in http://nuget.codeplex.com/workitem/426 - setting the Http Response Headers to Expire Web Content Immediately seems to work for me.

dfowler wrote Apr 28, 2011 at 9:00 AM

If you're hosting your own server and haven't updated it then you might run into this error.

dlpowell wrote Apr 28, 2011 at 1:56 PM

We've updated our NuGet.Server to 1.3. I'll get back to you if we still see the problem.

RobinM wrote May 3, 2011 at 10:34 AM

I'm getting this issue again. The server is at v1.3. The Http Response Headers are set to Expire Web Content Immediately.

Updating the last write time of the package on the server fixes the issue. I assume that's a temporary fix but we'll wait and see.

jesschadwick wrote May 17, 2011 at 10:51 PM

Fixed in v1.3 and you have to clear your IE cache at least once to make the error go away. If you cleared your IE cache and upgrade the NuGet.Server to the latest version, and it still persists, please re-open.

** Closed by jesschadwick 05/17/2011 2:51PM

RobinM wrote May 17, 2011 at 11:31 PM

This issue persists for me in v1.3 despite clearing IE cache.

RobinM wrote May 17, 2011 at 11:34 PM

I should also add that it happens daily for us. I'll re-open when I work out how...

thargy wrote Aug 3, 2011 at 12:44 PM

Sorry, still happens on 1.4 on custom server, even if clear IE cache. Updating write time still works most of the time, but occasionally that doesn't help either. I'm currently stuck with one package (that was fine yesterday) refusing to load. All the other packages worked again after updating write time.

dlpowell wrote Aug 3, 2011 at 5:59 PM

I agree with thargy. We still see the same behaviour too. We also periodically run a script to touch the packages which works most (though not all) of the time.

jesschadwick wrote Aug 3, 2011 at 6:29 PM

This issue still occurs with the latest NuGet Server version

dfowler wrote Aug 4, 2011 at 4:03 PM

The IE cache doesn't matter anymore and this shouldn't be happening at all. What did you do to make it repro.

mjedynak wrote Aug 10, 2011 at 9:40 AM

I use custom(private) Nuget feed for package A which depends on packages from both public feed and this private feed. I get this error when dependent package is being downloaded from private feed

NeilDuncan wrote Aug 17, 2011 at 3:23 PM

Replicated this today...

We have a large number of package versions in the feed.
Deleting some of the older versions caused the problem to disappear.

dkl wrote Aug 18, 2011 at 4:21 PM

I have the same issue. Seems to be problem of client - I downloaded and successfully unzipped the package from our internal Nuget.Server, but an attempt to install the package using VS Package Manager or powershell command line results in package verification error.

I don't know if it is related, but I installed the package successfully (v.1.0.1.1), then uninstalled it, then installed earlier version of the package (v.1.0.1.0) and then tried to upgrade the package to the newer version (v.1.0.1.1). Since than, I'm getting the error. Cleaning the cache in Fiddler did not help.

dkl wrote Aug 18, 2011 at 4:42 PM

Actually, restarting computer did help. I should have tried to turn it off and then on again in the first place:-)

fatalglory wrote Aug 19, 2011 at 5:20 AM

Thanks for the tip NeilDuncan, I had the same problem today. Had a package with around 20 versions, got this error while trying to update. I removed the half the versions (the oldest ones) and restarted our nuget vm, problem went away.

ericwood123 wrote Aug 30, 2011 at 7:34 PM

I experience the same issue but have yet to find a pattern to the cause. I removed some of the older versions and restarted the NuGet server. I'm now able to download some of the packages that NuGet had issues with in VS. I was able to open the packages in Package Explorer that could not be installed via NuGet in VS.

gaffa wrote Sep 6, 2011 at 1:37 AM

One possible hint for this issue - if I try and add a package from our internal NuGet by choosing the Online => 'Internal Packages' option, it occasionally fails. However, if I got to 'Recent Packages' and the package I want is in the list cos I've used it on another project, then that always seems to work.

Haacked wrote Sep 23, 2011 at 4:27 AM

Are you still running into this on the latest versions of NuGet?

gaffa wrote Sep 23, 2011 at 5:41 AM

Haven't got this one the recent upgrade, although I haven't added too many nuget packages recently to my projects, so it really hasn't had a chance to rear it's ugly head. I will keep a lookout

singletreeshane wrote Sep 23, 2011 at 3:35 PM

We have the same issue on a custom feed when trying to update to a new package. Very frustrating and it's bringing development to a halt. We are using the latest 1.5 and the latest server code.

Here's what I've done:
Reset IECache
Deleted local nuget cache
removed all but the newest packages from our custom feed server
restarted server
restarted VS

We are getting this error on 2 different dev machines.

Couldn't nuget at least give a detailed stack trace in the exception? I tried the console app with verbose output on the update and all I get is:
WARNING: Failed to download package correctly. The contents of the package could not be verified.

What is it in the package that can't be verified? A dependency? Any help would be appreciated.

Haacked wrote Sep 23, 2011 at 5:16 PM

That error means that we tried to compare the package hash stored in the database with the hash of the actual file and it failed. You said you're using a custom feed. Is it based on the NuGet.Server package? Which version?

singletreeshane wrote Sep 23, 2011 at 6:13 PM

We are using server version 1.5.20818.9011

Our packages are created via automated build. I forced a new build and the new version updates fine. Looks like this issue is hard to track down.

nekresh wrote Oct 11, 2011 at 8:17 AM

The problem seems to be in the hash calculation on the server side.
The hash provided by the server differs from the hash computed on the client, on the downloaded file or on the server (with SHA512).

I think this problem come from a mis-use of the SHA512 class which isn't thread-safe by instance (see http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512.aspx)
I've made a pull request with a unit test failing with the actual implementation and a new implementation which create a CHA512 crypto provider for each instance of CryptoHashProvider and pass the test (see http://nuget.codeplex.com/SourceControl/network/Forks/nekresh/nuget/contribution/1569)

neoita wrote Oct 27, 2011 at 9:18 AM

nuget is awesome but this bug is very frustrating.
please fix this!

cafedo wrote Oct 27, 2011 at 9:20 AM

This bug is very frustrating.
Peace.

rcappe wrote Oct 27, 2011 at 9:36 AM

We have the same issue on a custom feed (NuGet.Server 1.5.20902.9026)
This bug is really annoying every day restart the application pool.

Nekresh dont find the url http://nuget.codeplex.com/SourceControl/network/Forks/nekresh/nuget/contribution/1569

Any workaround or tip to fix it?

nekresh wrote Oct 27, 2011 at 10:15 AM

@rcappe no, I've made further tests and it wasn't solving this problem, so I deleted my pull request.

LordZoltan wrote Nov 7, 2011 at 9:07 AM

Just got the same problem today on our NuGet server (v1.5.20902.9026) - restarting the server's app pool worked. Curiously the server had only just been restarted anyway.

App pool is running as my own domain account as the package location is a UNC path.

anthonycarl wrote Nov 8, 2011 at 8:15 PM

We run local Nuget Feed and we get this error quite often. So much so, that we have recycling set on the feed every 180 minutes or 1000 requests.

Sometimes restarting IIS once doesn't clear it up. After several attempts it may go away.

It seems like it has something to do with server side caching that is triggered off of basic file information. For example, we store packages from the public feed on our private feed because some of our dev machines do not have open Internet access. When we get this error on our private feed on the packages that came from the public feed, I can re-download them from the public feed and drop them in the packages folder. This makes the issue go away for that particular package. The only difference I see between the old and new file is the create/modify dates have changed. The actual package version and contents are the same as far as I can tell.

To further test this, I saved the downloaded packages from the public feed in a different directory. The next time I got this error, I copied the files from that directory into the Nuget packages dir. This did not solve the problem and the files had the same create/modify date as the packages already in the Nuget packages dir. I then re-downloaded the file from the public feed and dropped it in the package dir. The problem went away again.

We use TeamCity to publish our internal packages to our private feed. When the problem affects those packages, kicking off a build in TeamCity that creates a new version of the package and publishes it makes it go away (assuming no dependent packages are suffering from this issue as well).

My Nuget server version says it is 1.6. I built it directly from the source available via Codeplex on 9/16/2011. I set it up directly in IIS on Windows Server 2008 R2. I was never able to get the feed up and running with Orchard CMS/database method posted on the Nuget website.

anthonycarl wrote Nov 8, 2011 at 10:12 PM

I may be stating the obvious, but it is failing because the 'packageHash' is different than the calculated hash of the downloaded buffer in PackageDownloader.cs:

// TODO: This gets held onto in memory which we want to get rid of eventually
byte[] buffer = downloadClient.DownloadData();

if (!_hashProvider.VerifyHash(buffer, packageHash))
{
     throw new InvalidDataException(NuGetResources.PackageContentsVerifyError);
}

I can't seem to figure out where the value for 'packageHash' comes from or how it is calculated (I assume from the server somehow). This may be because I don't think I have a complete debug environment setup correctly. I am debugging with the command line project. Any help is appreciated.

When I debug and skip over the line where the exception is thrown, the package is eventually downloaded (seems to try 4-5 times per package, not sure why). I am able to open up the downloaded file with the Nuget Package Explorer despite the hashes not matching up. Like I said before, sometimes restarting IIS clears it up sometimes it does not. A colleague was eventually able to get all packages with a combination of the command line and the VS Nuget GUI (they choked on different packages).

pranavkm wrote Nov 8, 2011 at 10:53 PM

We had a bug in our hash implementation that was fixed in 1.6. (http://nuget.codeplex.com/discussions/278108). Our guess is that there might be another bug in the way we read package metadata from disk - it is probably not performed in a thread safe way manner which might be a reason IIS resets do not work. I was planning on investigating the latter in 1.6oob.

My suggestions to you at this point:-
1) Wait for the 1.6 release (which should be soon). Perhaps the bug fix addresses your issue
If you are feeling adventurous, try the latest 1.6 build from our CI (http://ci.nuget.org). However please note that because of our changes to update version values to use semantic version, all clients would need to be updated to 1.6 as well.

2) Try the NuGet Gallery (https://github.com/NuGet/NuGetGallery/). This is not a final product but is stable enough for most intents and purposes.

anthonycarl wrote Nov 9, 2011 at 9:43 PM

I wasn't able to get the server.zip from the CI to work. Always got a 403 Forbidden when trying to access packages.

Instead, I updated to latest source from the repo and used the server.zip that it created. Worked with minimal IIS configuration.

I did use the VS Extension from the CI and that works fine. Adding the nuget command line to TeamCity was easy. I just dropped the command nupkg in TeamCityConfiguration\system\pluginData\jetbrains.nuget\nupkg, Teamcity automatically found it and upgraded the agents. The downside is I can't access the public nuget feed. Not a big deal since we store all needed packages on our private feed.

Haven't gotten this issue since I upgraded. Thanks for the help!

dhvik wrote Nov 18, 2011 at 10:23 AM

Performing an iisreset on the nuget feed server and clearing the local package cache seems to fix it temporarily

pranavkm wrote Nov 18, 2011 at 5:13 PM

Are you running the 1.6 version of the gallery?