NCrunch V5 not working for F# projects in Rider

I'm running 5.6.01 with the latest Rider, but unfortunately any F# projects are not building. This is reproducible by just creating a new F# project in Rider and enabling NCrunch so nothing specific to what I'm doing. All works fine for the Visual Studio version.

NCrunch: If you are experiencing problems in getting this project to build, have a look at https://www.ncrunch.net/documentation/troubleshooting_project-build-issues
..\..\..\..\..\Program Files\dotnet\sdk\8.0.204\FSharp\Microsoft.FSharp.Targets (331, 9): The specified task executable location "C:\Program Files\dotnet\sdk\8.0.204\FSharp\fsc.exe" is invalid.

Appreciate the Rider plugin is much more experimental, but really excited to use it (especially as F# support in rider is so good)

Thanks

Hi, thanks for posting.

It looks like the .NET SDK that you're using is somehow missing the fsharp compiler. Can you check through your SDK installations at C:\Program Files\dotnet\sdk to find the latest one that includes fsc.exe? You can then use this with NCrunch by setting the Build Sdk setting.

The .NET sdk doesn't include an f# compiler exe anymore (just fsc.dll). However Visual Studio does as part of a tools folder. NCrunch uses this when running in Visual Studio.

I've found a workaround by adding this Property to Directory.Build.Props to use the Visual Studio fsc.exe

<FscToolPath Condition="'$(NCrunch)' == '1'">C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools</FscToolPath>

This work for me as I already have Visual studio installed, but obviously not ideal to have this dependency for running in Rider.

When I build F# projects in Rider I can see in the logs that in order to run the f# compiler it runs

C:\Program Files\dotnet\dotnet.exe "C:\Program Files\dotnet\sdk\8.0.204\FSharp\fsc.dll"

I couldn't work out exactly what MSBuild property Rider is using to enable this build behavior, but I think if this could made the default for NCrunch Rider it would remove the need for Visual Studio workaround.

If you set the 'Build Sdk' property to point to VS2022 instead of a version of the .NET SDK, does the problem go away?

Yes that works too! (presume in much the same way)

Thanks