FSharp.Core version 6.0.5 has multiple content hashes.

[JustinWilkinson]

Please 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

1. Create a project that references FSharp.Core version 6.0.5, enable lock files and restore.
2. Install the 6.0.400 SDK.
3. 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

[vzarytovskii]

@KevinRansom it seems that it is because we didn't bump a version

[cmeeren]

All our builds have started failing with this error now. Are there any easier/better workarounds than what @JustinWilkinson described (pushing the package from NuGet to a private feed and incrementing the version)? We'd have to do this for hundreds of projects. (Turning off lock files is not an option at the moment.)

[cmeeren]

I tried pinning the .NET SDK version to 6.0.303 using global.json, but I get the same result. (I verified that the CI restore task is using SDK Version: 6.0.303.) Since this bug was introduced with 6.0.400, I thought that this should work, but I have probably misunderstood something. Can anyone explain why it does not help pinning the SDK to pre-6.0.400 on CI?

[hcoona]

I also meet this issue

[cmeeren]

Pinning the .NET SDK to 6.0.302 worked. 6.0.303 did not work.

[vzarytovskii]

I think it is an issue with that we didn't bump the version when we were getting the localization changes in, and it went to SDK but not to the NuGet.

[vzarytovskii]

Is removing FSharp.Core (6.0.5) from local nuget cache and having <DisableImplicitLibraryPacksFolder>true</DisableImplicitLibraryPacksFolder> helping the build?

This should disable library-packs and it will be using FSharp.Core from the NuGet.

[bddckr]

Is removing FSharp.Core (6.0.5) from local nuget cache and having <DisableImplicitLibraryPacksFolder>true</DisableImplicitLibraryPacksFolder> helping the build?

Removing that version from the local cache does indeed help. For my team, this reliably pulls down the version found on NuGet.org. Note, however: We are using DisableImplicitNuGetFallbackFolder and NOT DisableImplicitLibraryPacksFolder. I have not tried the latter, as the former works fine for us, as long as the previously cached version is removed once.

So the steps are

1. Ensure your projects use <DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder>.
2. Delete the locally cached copy of 6.0.5 out of your .nuget folder, i.e. delete the folder C:\Users\<your windows user>\.nuget\packages\fsharp.core\6.0.5 on Windows.
3. Restore packages and update your lock files. This will write the other contentHash into the lock files.
4. Make those new lock files available to the rest of the team.
5. Ask every team member to wipe their cached copy followed by a restore as well.
6. If your CI caches restored packages, make sure to wipe the cached copy there as well.

[cmeeren]

A couple of questions:

1. What exactly is DisableImplicitLibraryPacksFolder? Web searches turn up nothing useful about this. I'm therefore hesitant to use it (especially since I am now using the 6.0.302 SDK as a simple and reliable workaround).
2. In the steps posted by @bddckr above, would it cause problems if some projects/solutions on your machine did not use DisableImplicitLibraryPacksFolder? Would they then try to place the package from the SDK in the NuGet cache (and win if you opened them first)?

[bddckr]

Apologies, I copied the wrong property and confused myself.

My team is using DisableImplicitNuGetFallbackFolder like the original poster said. This works fine - as long as every team member ensures to delete the cached version that has the "wrong" hash. We do NOT use DisableImplicitLibraryPacksFolder.

I've edited my earlier message to fix that.

[bddckr]

Both properties are seemingly very closely related for the same thing - the extra search paths pointing to files not sourced from NuGet.org (or your other configured feeds):
https://github.com/dotnet/sdk/blob/a30e465a2e2ea4e2550f319a2dc088daaafe5649/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.NuGetOfflineCache.targets#L20-L29

I'm thinking about enabling both moving forward. I believe DisableImplicitLibraryPacksFolder should be set to true for the same reason the recommendation is to enable DisableImplicitNuGetFallbackFolder:
https://github.com/dotnet/reproducible-builds/blob/d6b3923a0908249a8d6416a1e2d02c51e53b6cce/Documentation/Reproducible-MSBuild/Techniques/DisableImplicitNuGetFallbackFolder.md

[cmeeren]

My team is using DisableImplicitNuGetFallbackFolder like the original poster said. This works fine - as long as every team member ensures to delete the cached version that has the "wrong" hash. We do NOT use DisableImplicitLibraryPacksFolder.

Not sure what you mean by "works fine". I have long used DisableImplicitNuGetFallbackFolder (and not DisableImplicitLibraryPacksFolder), deleting the NuGet cache did not change the content hash in the lock files after dotnet restore --force-evaluate. Everything builds fine locally (either way), but the CI build fails.

I'm thinking about enabling both moving forward. I believe DisableImplicitLibraryPacksFolder should be set to true for the same reason the recommendation is to enable DisableImplicitNuGetFallbackFolder:

Makes sense. Would be great to have someone else confirm this.

[bddckr]

Not sure what you mean by "works fine". I have long used DisableImplicitNuGetFallbackFolder (and not DisableImplicitLibraryPacksFolder), deleting the NuGet cache did not change the content hash in the lock files after dotnet restore --force-evaluate. Everything builds fine locally (either way), but the CI build fails.

Hmmm. I just set up a fresh Windows VM (for something unrelated) and tried it there as well. You're right. It keeps using the library-packs folder. I must have gotten my results wrong when I was testing DisableImplicitLibraryPacksFolder earlier as well.

Finally, to confirm (sorry for the back and forth): If I'm setting both DisableImplicitNuGetFallbackFolder and DisableImplicitLibraryPacksFolder to true, the original content hash is used - the hash I got from before the 6.0.400 SDK was installed. As such, the lock file stays the same, and I don't have to ask my team members to wipe their cached copy. I simply need to ensure they are on the latest project state - using <DisableImplicitLibraryPacksFolder>true</DisableImplicitLibraryPacksFolder>.

tl;dr: vzarytovskii's suggestion above works.