fix: ship FSharp.Core with the F# fixture assemblies

[jeremydmiller]

Closes #580

Root cause

The issue reported the symptom (no FSharp.Core in FSharpTypes' output, no entry in its deps.json) but not the mechanism. It's in the F# SDK:

<!-- sdk/10.0.101/FSharp/Microsoft.FSharp.NetSdk.props:83-86 -->
<PropertyGroup Condition=" '$(ManagePackageVersionsCentrally)' == 'true' ">
  <DisableImplicitFSharpCoreReference Condition="...">true</DisableImplicitFSharpCoreReference>
</PropertyGroup>

Central package management turns off the F# SDK's implicit FSharp.Core reference. Confirmed directly:

$ dotnet msbuild src/FSharpTypes/FSharpTypes.fsproj -getProperty:DisableImplicitFSharpCoreReference
  "DisableImplicitFSharpCoreReference": "true"

The projects compiled anyway because fsc falls back to the FSharp.Core bundled with whichever SDK is running when nothing else supplies one. That's what made this fail quietly instead of loudly — and it also means the fixtures were being compiled against a different FSharp.Core than the repo pins, varying with the installed SDK.

Reflecting over the output then threw FileNotFoundException for FSharp.Core, Version=10.0.0.0 — the SDK-bundled version it had been compiled against, which was never deployed.

Fix

An explicit <PackageReference Include="FSharp.Core" /> in both F# projects — src/FSharpTypes and src/CodegenTests.FSharpFixture. Under CPM this resolves to the existing central 9.0.303, so it reconciles with CodegenTests' pin rather than adding a second conflicting one, as the issue asked.

src/FSharpCodegenTarget was also flagged as worth checking — it's a C# project, so it never had the gap; it now picks up FSharp.Core transitively.

Verification

Before/after on CoreTests' output directory:

BEFORE:  FSharpTypes.dll
AFTER:   FSharp.Core.dll   FSharpTypes.dll

Answering "what is the fixture actually proving today?"

The issue asked this, and the answer is worth recording: the existing ValueTypeInfoTests F# tests were passing on a broken fixture. typeof() and member lookup never force assembly-level attributes to resolve, so they never touched the missing dependency.

New src/CoreTests/Reflection/FSharpTypesFixtureTests.cs guards the fixture itself. Removing the PackageReference again:

Failed  fsharp_core_is_an_actual_reference_of_the_fixture      System.IO.FileNotFoundException
Failed  the_assembly_level_attributes_can_be_resolved          System.IO.FileNotFoundException
Failed  the_fsharp_types_carry_resolvable_fsharp_core_attributes  System.IO.FileNotFoundException
Passed  every_type_in_the_fixture_can_be_loaded

The exact exception from the issue, and the one that passes either way is GetTypes — which is exactly why this hid for so long. That's noted in the test so nobody mistakes it for a guard.

Test results

Suite	Result
CoreTests (net9.0)	479 passed (475 baseline + 4 new)
CoreTests (net10.0)	479 passed
CodegenTests (net9.0)	419 passed
CodegenTests.FSharp compile gate	1 passed

No new compiler warnings — the fixture's four pre-existing FS3261 nullness warnings are unchanged in count.

🤖 Generated with Claude Code