F# uses central package management and there won't be any test runs

[vst-h]

Replicated in a repository(https://github.com/vst-h/FsTestNoRun) with Github Action dotnet test output:

[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 8.0.11)
[xUnit.net 00:00:00.07] Skipping: TestProject1 (could not find dependent assembly 'FSharp.Core, Version=8.0.0')
No test is available in /home/runner/work/FsTestNoRun/FsTestNoRun/TestProject1/bin/Debug/net8.0/TestProject1.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.

When I rename Directory.Packages.props to not use central package management, then it runs the tests

However, I'm using the central package management in my c# project and everything works fine.

[vst-h]

Solved, need to add <PackageReference Include="FSharp.Core" /> inside one of the project dependencies.

[bradwilson]

Isn't FSharp.Core always needed for F# projects? (It's name seems to imply it is. 😂)

We have one place where we dynamically look for F#: by testing to see if we can find the type Microsoft.FSharp.Control.FSharpAsync<T>, which is what we expect to see if an F# test is natively F#-style async (as opposed to seeing Task<T> or ValueTask<T> from C# or VB). But the only thing that should affect would be whether we properly handle F# async tests, and I find it impossible to believe we wouldn't be able to find that type in any F# project at runtime.

So I remain confused...

[vst-h]

The test works fine when central package management is not used. Added central package management and then couldn't find FSharp.Core, probably didn't copy FSharp.Core to the output. It should be a central package management problem.

[vst-h]

Found a related issue, NuGet/Home#11949

[bradwilson]

Oof, that's an old one, too. 😞

Honestly I haven't had much luck using central package management. I tried moving to it for the samples project (I'm porting and updating the v2 samples for v3 in anticipation of 1.0), and I've definitely run into edge cases where I'm seeing things just not working correctly (e.g., 3rd party MSBuild logic that expects to be able to extract Version from <PackageReference>). It also does things I didn't particularly like, like forcing versions of packages that are only used once into a central location; so I kept with my <PropertyGroup> solution for common package versions, and allow the one-offs to float in their respective locations.