NuGet error when using RestorePackagesWithLockFile?

[Hest]

I am trying to follow https://www.telerik.com/blogs/azure-devops-and-telerik-nuget-packages

but I keep getting error NU1403: Package content hash validation failed for Telerik.Recurrence.Trial.0.2.0. The package is different than the last restore.

This error is generated because my committed packages.lock.json (which is generated by RestorePackagesWithLockFile = true) is somehow different, even though I use the same credentials.

What can I do?

 

[Tania]

I had this same issue and I resolved it by upgrading theTelerik.UI.Blazor package to 4.1.0 when it was 4.0.1 previously (I thought we were on this latest release but I was tricked by the similarities between the 4.0.1 and 4.1.0 numbers.

I think they might have pushed new versions of the Datasource and Recurrence packages without updating the version number which was causing the newer package to be resolved and the different hash (though my understanding of nuget is very limited, just my assumption).

Just posting this here in case anyone else comes across this.

If you're not ready to upgrade to 4.1.0 for some reason, don't clear your nuget cache 😅.

Also, seems like other machines/build server needs to have it's cache cleared as well before you'll be able to restore successfully after upgrading the package 😭

[Robert]

I have the same issue after introducing packages.lock.json to speedup the restore on the build server, we currently use Telerik.UI.for.Blazor version 3.2.0:



Package content hash validation failed for Telerik.Recurrence.0.2.0. The package is different than the last restore. 



Deleting all files from the nuget cache on the build server didn't work either ;(

update:

I deleted my local cache and got different hash values for Telerik.Recurrence.0.2.0 in the packages.lock.json. They were the same on the build server making the build succeeded.

So what happened to that package resulting in a different hash??

 

[Dimo]

@Robert - there are two occasions in the past when we released the same package with a new hash by mistake. After the first time, we made changes in our release process to avoid this, but the second time the reason was completely different. I do hope this won't happen again.

Sorry about the trouble.