FSharp.Core version 9.0.300 has multiple content hashes

[zivkan]

Root cause of:

• Package content hash validation failed for FSharp.Core.9.0.300. NuGet/Home#14380

Using my knowledge of NuGet to get the content hash for the nupkgs:

source	content hash
SDK 9.0.301	cU3+oEWUbuOtdKeos4QsWSV0e3+B8K4yAAx/bxv7qec=
SDK 9.0.300	nLg0WYZlcWFYf4eI5BWo2yIU1eYlSCnwHlqS0JlmdiI=
nuget.org	nLg0WYZlcWFYf4eI5BWo2yIU1eYlSCnwHlqS0JlmdiI=

So, it looks like the nupkg from the 9.0.300 SDK build was uploaded to nuget.org, but then the 9.0.301 SDK re-created it rather than re-using the existing nupkg. This breaks customers using lock files for deterministic restore.

Note that NuGet's pack is not deterministic. It was tried at one point, but deployment tools that used only a file's timestamp assumed that the deployment target was already up to date for assets coming from the package, and then the deployed app did not work correctly since files coming from the nuget package were not deployed. NuGet had to immediately roll back deterministic pack as it affected too many customers. Therefore, even if a compiler is deterministic, pack is not because of the timestamp written to the zip file's central directory.

[zivkan]

I'm unfamiliar with F#. Is there documentation somewhere on how to disable using the SDK's "library-packs" source, to force nuget to download from nuget.org instead?

[baronfel]

There's not really a lot of documentation on this area at all. The magic property is here: https://github.com/dotnet/sdk/blob/main/src%2FTasks%2FMicrosoft.NET.Build.Tasks%2Ftargets%2FMicrosoft.NET.NuGetOfflineCache.targets#L2

Essentially the logic was

• C# projects don't need to download anything other than an SDK to be able to compile simple things
• F# projects typically do - they need fsharp.core.
• It would suck to require a network connection for very basic things
• The SDK already had a concept for 'allow packages to come from a special place', and the library packs folder was that place.

[T-Gro]

I have found this for disabling the folders:

<DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder>
<DisableImplicitLibraryPacksFolder>true</DisableImplicitLibraryPacksFolder>

For the original issue:
Would this be solved by uploading the SDK 9.0.301 version of FSharp.Core to nuget under the version name 9.0.301 ? (not sure if we can do that)

[baronfel]

@mmitche is this a thing that our system can handle?

[mmitche]

What this means, I think, is that FSharp created a new package that got inserted into the SDK for 301, but the branding for the packages did not get updated. Meaning that a new 9.0.300 was created with new content. Often this gets noticed by the staging pipeline, but it may not in this case. There should be an explicit test for it (does package X we are about to ship exist on nuget.org).

There's not much recourse for 9.0.301. There is no 9.0.301 package available. and creating one would change the hash, of course. It will need to be fixed in 9.0.302 by branding fsharp

[T-Gro]

The linked PR, if I understood it correctly, should flow the branding change from F#'s 17.14 to SDK's release/9.0.3xx - I can trigger manually to speed it up.
Is that what you had in mind, @mmitche ?

[mmitche]

Yes. That will flow to 9.0.300..it may not make 9.0.302 though. How critical is this, do you think?