System.Formats.Cbor.Tests fails to compiled with daily vmr SDK

[tmds]

In our internal CI, some jobs compile runtime repo with an SDK that comes from a daily vmr job.

These jobs are failing with:

error CS0012: The type 'FSharpFunc<,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. [/var/home/tmds/workspace/runtime/src/libraries/System.Formats.Cbor/tests/System.Formats.Cbor.Tests.csproj::TargetFramework=net10.0]

I diffed the compilation cmdline for System.Formats.Cbor.Tests.dll between working (SDK as downloaded by runtime repo) and non-working (SDK from our daily vmr build):

@@ -16,7 +16,7 @@
 /nullable:enable
 /reference:/var/home/tmds/.nuget/packages/fscheck/2.14.3/lib/netstandard2.0/FsCheck.dll
 /reference:/var/home/tmds/.nuget/packages/fscheck.xunit/2.14.3/lib/netstandard2.0/FsCheck.Xunit.dll
-/reference:/var/home/tmds/.nuget/packages/fsharp.core/9.0.200-beta.24606.2/lib/netstandard2.1/FSharp.Core.dll
+/reference:/var/home/tmds/.nuget/packages/fsharp.core/9.0.200-beta.25056.5/lib/netstandard2.1/FSharp.Core.dll
 /reference:/var/home/tmds/repos/runtime/artifacts/bin/microsoft.netcore.app.ref/ref/net10.0/Microsoft.CSharp.dll
 /reference:/var/home/tmds/.nuget/packages/microsoft.diagnostics.runtime/1.0.5/lib/netstandard2.0/Microsoft.Diagnostics.Runtime.dll
 /reference:/var/home/tmds/.nuget/packages/microsoft.dotnet.remoteexecutor/10.0.0-beta.25058.4/lib/net8.0/Microsoft.DotNet.RemoteExecutor.dll
@@ -221,7 +221,7 @@
 /features:nullablePublicOnly
 /analyzerconfig:/var/home/tmds/repos/runtime/.editorconfig
 /analyzerconfig:/var/home/tmds/repos/runtime/eng/CodeAnalysis.test.globalconfig
-/analyzerconfig:/var/home/tmds/repos/runtime/.dotnet/sdk/10.0.100-alpha.1.24610.7/Sdks/Microsoft.NET.Sdk/codestyle/cs/build/config/analysislevelstyle_default.globalconfig
+/analyzerconfig:/tmp/tmp.7qq8g7mMIn/sdk/10.0.100-alpha.1.25063.1/Sdks/Microsoft.NET.Sdk/codestyle/cs/build/config/analysislevelstyle_default.globalconfig
 /analyzerconfig:/var/home/tmds/repos/runtime/artifacts/obj/System.Formats.Cbor.Tests/Debug/net10.0/System.Formats.Cbor.Tests.GeneratedMSBuildEditorConfig.editorconfig
 /analyzer:/var/home/tmds/.nuget/packages/xunit.analyzers/1.4.0/analyzers/dotnet/cs/xunit.analyzers.dll
 /analyzer:/var/home/tmds/.nuget/packages/xunit.analyzers/1.4.0/analyzers/dotnet/cs/xunit.analyzers.fixes.dll

The FSharp.Core version is slightly higher because it is produced by a daily vmr build. Other than that, the flags are all very similar.

@ViktorHofer I'm not sure why this fails to compile with our daily build. Do you have some suggestions to debug this further?

cc @omajid

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

I diffed the compilation cmdline for System.Formats.Cbor.Tests.dll between working (SDK as downloaded by runtime repo) and non-working (SDK from our daily vmr build)

Note that the SDK used in the VMR is currently different to the one used here in runtime. #111311 moves runtime to a newer SDK.

Unfortunately, no I have no idea. Double check that /var/home/tmds/.nuget/packages/fsharp.core/9.0.200-beta.25056.5/lib/netstandard2.1/FSharp.Core.dll contains the FSharpFunc<,>.

[tmds]

After looking further at the differences between working and non-working FSharp.Core dlls, I think this may be caused by dotnet/arcade#15380.

[tmds]

After looking further at the differences between working and non-working FSharp.Core dlls, I think this may be caused by dotnet/arcade#15380.

@ViktorHofer this is where the regression occurred. It seems the FSharp.Core is getting signed with a different key that doesn't run into dotnet/fsharp#17451. Disabling that signing results into this (product) issue. I'm going to make a PR that reverts dotnet/arcade#15380, and re-open #111123.