FSharpTypes.dll ships without FSharp.Core, breaking reflection over it

[jeremydmiller]

What

src/FSharpTypes/FSharpTypes.fsproj builds to an output directory containing only FSharpTypes.dll and FSharpTypes.deps.json — no FSharp.Core.dll, and no FSharp.Core entry in its deps.json:

$ ls src/FSharpTypes/bin/Debug/net9.0/
FSharpTypes.deps.json
FSharpTypes.dll

The same gap propagates to CoreTests, which project-references it.

Consequence: anything that reflects over FSharpTypes.dll — enumerating its custom attributes, resolving its types — throws

System.IO.FileNotFoundException: Could not load file or assembly
'FSharp.Core, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

because the F# compiler emits assembly-level attributes (FSharpInterfaceDataVersionAttribute) whose types live in FSharp.Core.

Pre-existing, not a regression

Verified against a clean worktree at e41eb2e (2.36.2, before #576/#577/#578) — FSharpTypes.dll shipped without FSharp.Core there too. This has presumably been true since the project was added.

How it surfaced

The xunit 3 migration (#577). v3 test projects are executables, so Assembly.GetEntryAssembly() became CoreTests.dll instead of testhost.exe. JasperFxOptions.HasReferenceToJasperFxTool walks the entry assembly's references and reads each one's attributes, so it reached FSharpTypes and blew up — 15 CoreTests failures.

#577 fixed the product side (that walk is best-effort and now skips assemblies it can't load, which it should have done all along — see the commit for why that matters to real consumers). It deliberately did not paper over this packaging gap, which is still real and still unfixed.

Why it's worth fixing

FSharpTypes exists to give CoreTests real F# types to reflect over. An F# assembly that cannot actually be reflected over is a weak fixture — tests that appear to exercise F# type handling may be silently skipping it. Worth confirming what the fixture is actually proving today.

Notes for whoever picks this up

• No FSharp.Core PackageReference in the fsproj; it relies on the F# SDK's implicit reference. Something is stopping that from flowing to output.
• The requested version is 10.0.0.0 (from SDK 10's F# compiler), while CodegenTests explicitly pins FSharp.Core 9.0.303. Any fix should reconcile those rather than adding a second, conflicting pin.
• src/CodegenTests.FSharpFixture and src/FSharpCodegenTarget are separate F# projects worth checking for the same gap.