I’m sporadically getting errors like the below error, or rather - not sporadically, but about 30-50% of the times the deployment is run. Nuget feed, Octopus server and tentacle are all on the same machine in this testing period.
I’ve sometimes had success with rebuilding the exact same package content-wise on our Team City server, just incrementing the version number (by using TC build number).
We’re running version 0.8.413.2048, downloaded today.
2011-10-14 09:49:44 INFO Deploying release ‘11.5.3.95’ of project ‘UNNAMEDCUSTOMER B2C Environment’ into environment 'test’
2011-10-14 09:49:44 INFO Downloading NuGet package UNNAMEDCUSTOMER.WebAdmin.WebUI 1.0.10.187 from feed: 'http://localhost/nugetgallery/nuget’
2011-10-14 09:49:47 DEBUG Found package UNNAMEDCUSTOMER.WebAdmin.WebUI 1.0.10.187
2011-10-14 09:49:47 ERROR System.IO.InvalidDataException: Failed to download package correctly. The contents of the package could not be verified.
at NuGet.PackageDownloader.DownloadPackage(IHttpClient downloadClient, Byte[] packageHash, IPackageMetadata package)
at NuGet.DataServicePackage.DownloadAndVerifyPackage(IPackageRepository repository)
at NuGet.DataServicePackage.GetStream()
Hi,
Thanks for reporting this. A few people have had the same problem with NuGet.Server, but I’ve never been able to reproduce it. Could you supply some details about your configuration - Windows version, x86/x64, NuGet.Server version, IIS integrated/classic mode.
Out of curiosity, how do you use TeamCity to produce and publish your NuGet packages?
Paul
I know I’ve reported this before, but it’s just happened to me again on the latest Octopus build 
Usually I have to queue a new build, hope the release page picks it up without timing out too much (this appears to happen more often after a release page timeout than if the release page works first time. That may be misleading though, or just my perception) and then deploy the new build.
Windows Server 2008 x64
NuGet.Server v1.5.20902.9026
IIS Integrated mode
Hi Neil,
How are you publishing packages to NuGet? Just xcopying packages to the NuGet.Server’s /Packages folder, or using NuGet push?
Paul
Hi,
I just published a new build to:
This build adds a lot of diagnostics to Octopus around why a package download may have failed, as well as some retry logic. I’d appreciate if you could give it a try. Please check the output of any releases you do, as they will contain some diagnostics about the package hash and URL’s used.
This was just an Octopus change, not Tentacle, so you only need to upgrade the server. As always please make sure to stop the Octopus service before uninstalling.
Please let me know how this goes for you,
Paul
Hi,
The problem appears to be due to this NuGet.Server issue:
http://nuget.codeplex.com/workitem/1489
NuGet is telling Octopus one hash, but the file (which is valid) has a different hash. Recycling the app pool forces NuGet.Server to re-calculate the hash.
I’m going to spend some time debugging NuGet.Server to see why it is caching incorrect values.
Paul
Sorry about the lateness in getting back to you.
Thank you for investigating. I’m running this on a Windows 7 (x64 Enterprise) workstation during testing, but will be running on Windows 2008 R2 later on.
The case you have found seems to be at the core of the issue. Would an alternative be to simply ignore this hash and do a “manual” unpack test of the .nupkg? Atleast make it optional so it can be turned on and off by the admin of the Octopus server?
I’m just copying the file to the /Packages folder.
Have updated Octopus and will post any diagnostics here when this next occurs.
(on that note, one thing that always wrong-foots me when I update Octopus is pressing the ‘Update’ button just gives a message in the console that “Service is already installed” - everytime I think I’ve done something wrong, as I expect it to uninstall the old version and install a new one. I know you’re working on the installer for 1.0, but just wanted to flag this as a moment of friction when updating!)