PackageHash on NuGet.Server

Developer
Jan 26, 2012 at 6:23 PM
stevescotthome wrote Today at 9:44 AM
@pranavkm
This is a brand new install, I used exsiting nuget packages up until today when I tried to create my own...and some work, some fail with this error

I do an UnInstall and them Install with the PM, it says it's installing Nuget.Server 1.6.1, the .dll version though everywhere is 1.6.0?

Where can I get 1.6.2? Install-Package NuGet.Server 1.6.2 seems to crap out :)

(thanks for the help by the way!)

 

 

 

Developer
Jan 26, 2012 at 6:27 PM

I'm sorry, I meant 1.6.1. The binaries were labeled 1.6.0 and don't necessarily match the package version. Are you able to install these packages if you're using a local repository (just create a directory and add it as a source) instead of NuGet.Server?

Does the package hash issue consistently happen even after you restart the server? If so, do you think you could attach a package (upload it to a file share site and link it) and give us repro steps? Might make it easier to track down what's going wrong. I have a strong feeling it's probably not related to the issue in the work item listed earlier.

Jan 26, 2012 at 7:18 PM

Yeah, doesn't matter how many times I rebuild or restart the apppool it's always there :/

I checked, and yes running 1.6.1 (thats whats in the local Packages folder)

PM> Install-Package ResourcePackage -Source http://myserver/nuget

I am able to install the package fine if I use the VS2010 PM and point it at my local server source.  But using the C# API "GetFiles()" always crashes on the one "bad" package which installs fine.  It's really even nothing but a test package with a couple random .net assemblies added

Video: http://screencast.com/t/uuvVoubugg

Package: http://dl.dropbox.com/u/3234184/ResourcePackage.1.0.0.zip

Any idea?

Jan 26, 2012 at 8:10 PM

Also, if I try and use the API to install it gives me this "

"Failed to download package correctly. The contents of the package could not be verified. ""
Developer
Jan 27, 2012 at 6:10 AM

Could you try deleting the local cache? It's located under %LocalAppData%\NuGet (there's a clear cache button in the VS settings dialog for NuGet). Doesn't seem to be anything particularly wrong with your package. If that does fix it, we'd be interesting in figuring out what your repro steps were that resulted in this error message popping up.

Jan 27, 2012 at 12:49 PM

Yeah like i said the package installs just awesome on the VS commandline but any attempt to open it via the NuGet API results in bad package errors :/  Were you able to open it?

Clearing the cache had no effect, although its nice to know that it exists now :)

Again, thanks so much for trying to figure this one out, you've been a great help.

Steve

Developer
Jan 27, 2012 at 3:39 PM

Was able to run it from the server as also by read it by invoking it from our APIs.

            var repo = new NuGet.DataServicePackageRepository(new Uri("http://localhost:40221/nuget"));
            var packageFiles = repo.GetPackages().First().GetFiles(); // GetFiles triggers the package download
            Console.WriteLine(packageFiles.Count());

In 1.7, we've removed the verification step (the hash was originally used to validate packages downloaded from external hosts, something we no longer support), so perhaps using a CI build (http://ci.nuget.org:8080) should solve the issue. However it would be great if you could debug through the current code (symbols are on http://www.symbolsource.org) and see if you're hitting some sort of edge case. 

Jan 27, 2012 at 6:25 PM

Sure I'd love to debug, but if I could get my hands on 1.7 right now just for deadline constraints (after I debug) I hope that's doable too :)

I'm a bit new to this, can you give me some instructions?  (not on debugging in general, but getting the symbols...I signed up for an account on that site, but not sure where to go from there)

Steve

Developer
Jan 27, 2012 at 6:30 PM

If you just care for our 1.7 binaries head to the CI server (http://ci.nuget.org:8080), log in as guest and get the NuGet.Core.1.7 nupkg from our artificats directory. We really ought to turn on TeamCity integration, but you should be able to install our latest bits that way.

Symbol source as meant for debugging and David Ebbo has a great article on how to go about using it - http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-packages-with.html

Jan 27, 2012 at 6:44 PM

Thanks, youve been awesomely helpful, I'll let you know :)

Jan 27, 2012 at 8:22 PM

Well I followed that debug article, but when I debugged it didn't dump me anywhere outside of my code to continue debugging :/

ANYWAY... 1.7 Core definitely fixes it regardless.  Once I added that to my webapps assembly (not the server instance) it worked fine.  Now I haven't tried creating new packages yet, but I think it'll be okay.

Sep 19, 2012 at 8:31 AM

Was this ever fixed? It seems like I'm having the same issue and I'm running the 1.7 version of Nuget.Server with the 1.7 version of Nuget.Core.

I've seen it fail with two different error messages:

Message 1: System.IO.InvalidDataException: Failed to download package correctly. The contents of the package could not be verified.

Message 2: System.Exception: The package could not be downloaded from NuGet. Please see above errors for details. If you are getting a package verification error, try switching to a Windows File Share package repository to see if that helps.

I get the error when Octopus deploy (which I use for deployment) tries to download the packages. I can't swith to file share since we need the server so that the infrastructure team has control over how we access the network (I know it is redicolous, but that is the reality I have to live in).