Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
FSharp.Core version 6.0.5 has multiple content hashes.
See original GitHub issuePlease provide a succinct description of the issue.
Version 6.0.5 of the FSharp.Core library seems to have two different contents depending on where it is delivered from.
The version bundled in the SDK (found under C:\Program Files\dotnet\sdk\6.0.400\FSharp\library-packs stems from this commit.
The version published on NuGet.org stems from this commit.
In our builds, we make use of packages.lock.json and global.json files to ensure repeatable builds across different machines.
We make use of the below in a Directory.Build.props file to ensure hashes are the same, and this has worked historically up until the 6.0.400 SDK release.
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
<DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder>
The version on NuGet.org predates the version in the SDK, so the content hash on local builds seems to update but our pipelines are failing with the error:
error NU1403: Package content hash validation failed for FSharp.Core.6.0.5. The package is different than the last restore.
Given the hashes (and the content) are indeed different, this is expected, what is unexpected is the delivery of two distinct packages with the same version number.
Repro steps
- Create a project that references
FSharp.Coreversion 6.0.5, enable lock files and restore. - Install the
6.0.400SDK. - Restore packages again.
Expected behavior
The content of the FSharp.Core package (version 6.0.5) delivered by the 6.0.400 SDK should match that on NuGet.org.
Actual behavior
The content of the FSharp.Core package (version 6.0.5) delivered by the 6.0.400 SDK is different to that which is delivered on NuGet.org.
Known workarounds
We have downloaded the package from NuGet.org and assigned it version 6.0.5.1 in our own feed to force it to pick up a new version.
- Operating system - Windows
- .NET Runtime kind - .NET 6.
- Editing Tools - Visual Studio version 17.3
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:27 (20 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Yeah, this should be closed I think, nothing we can do for this particular version. Should be fixed for future ones (I will also have a CI gate in place to check it won’t happen again).
Okay, I believe I know what this is. It highlighted a bug in the sdk publish process that caused them to not update the package in the upload cache. I believe this release is the one they discovered it with and it will be fixed in the next release. I will follow up with @mmitche later today and report back if necessary.