Can't build VisualFSharp.sln using `dotnet` or Rider

[auduchinok]

Previously it always worked after a one time build.cmd call. Now it fails, which means IDEs that use dotnet build no longer can build this solution.

Eugene.Auduchinok@NVC00221 MINGW64 /c/Developer/fsharp-vs (main)
$ dotnet build VisualFSharp.sln
Restore complete (3,2s)
  FSharp.Core netstandard2.0 failed with 1 error(s) (0,6s)
    C:\Developer\fsharp-vs\artifacts\Bootstrap\fsc\Microsoft.FSharp.Targets(354,9): error MSB6006: "fsc.exe" exited with code -2147450730.
  FSharp.UIResources succeeded (0,2s) → artifacts\bin\FSharp.UIResources\Debug\net472\FSharp.UIResources.dll
  shims succeeded (0,1s) → artifacts\bin\shims\Debug\net472\shims.dll
  FSharp.Core netstandard2.1 failed with 1 error(s) (0,0s)
    C:\Developer\fsharp-vs\artifacts\Bootstrap\fsc\Microsoft.FSharp.Targets(354,9): error MSB6006: "fsc.exe" exited with code -2147450730.
  FSharp.Benchmarks.Common failed with 1 error(s) (0,1s)
    C:\Developer\fsharp-vs\artifacts\Bootstrap\fsc\Microsoft.FSharp.Targets(354,9): error MSB6006: "fsc.exe" exited with code -2147450730.
  FSharp.Editor.IntegrationTests succeeded (0,1s) → artifacts\bin\FSharp.Editor.IntegrationTests\Debug\net472\FSharp.Editor.IntegrationTests.dll
  CSharp_Analysis succeeded (1,4s) → artifacts\bin\CSharp_Analysis\Debug\netstandard2.0\CSharp_Analysis.dll
  MicroPerfCSharp succeeded (1,7s) → artifacts\bin\MicroPerfCSharp\Debug\net10.0\MicroPerfCSharp.dll
  Microsoft.CommonLanguageServerProtocol.Framework.Proxy succeeded (2,4s) → artifacts\bin\Microsoft.CommonLanguageServerProtocol.Framework.Proxy\Debug\net8.0\Microsoft.CommonLanguageServerProtocol.Framework.Proxy.dll
  FSharp.ProjectSystem.Base succeeded (3,5s) → artifacts\bin\FSharp.ProjectSystem.Base\Debug\net472\FSharp.ProjectSystem.Base.dll
  FSharp.ProjectSystem.PropertyPages succeeded (2,6s) → artifacts\bin\FSharp.ProjectSystem.PropertyPages\Debug\net472\FSharp.ProjectSystem.PropertyPages.dll

Build failed with 3 error(s) in 9,4s

This is an almost clean Win11 machine with only .NET SDK, Rider/VS and Git for Windows installed.

The shell used is Bash from Git for Windows in Windows Terminal.

[edgarfgp]

Same here. Im on macOS and can't build or run tests when using main.

[auduchinok]

@T-Gro Could someone investigate this please? It prevents any work needing VS-related changes, like #17494.

[T-Gro]

Could you please capture a binlog to see the fsc.exe input and output?
I suspect some wrong/missing init of a project property

[auduchinok]

@T-Gro Sure! vf.binlog.zip

[majocha]

It's again the unreleased dotnet sdk missing.
To me this happens when building from VS. Out of desperation I copy the local contents of .dotnet, that the build script downloaded, into system wide "C:\Program Files\dotnet" and it usually helps.

[T-Gro]

The very new VS2026 which has been just released should support the

    "paths": [
      ".dotnet",
      "$host$"
    ],

pointer, the previous did not (that is why I was using the start-vs-FsharpSln.cmd script in repo root).
This similarly applies to a base SDK one has - if it is lower then NET10p3 or so, it also does not understand the paths property unfortunately. The build script handles that, mere dotnet (if the globally installed SDK is lower than 10p3) will not.

Luckily this should be a temporal problem, but of course I do understand the frustration when basic commands do not work and would love to improve this further. Just at the moment, I do not know a better state of the art we could do while still using latest SDK for dogfooding.

[auduchinok]

The very new VS2026 which has been just released should support the

Sorry, I don't understand how an IDE release is related to the broken dotnet build command. I do have the latest released .NET SDK preview installed, but it doesn't help, as you can see in the binlog.

[T-Gro]

The IDE reference was meant to @majocha's comment about building from VS, I apologize for spaghetting this chat.

Is the eng/common/dotnet.[sh|cmd] script usable in this scenario, or not really?
If we do not find a way (e.g. something similar to start-vs-FsharpSln.cmd, but for Rider and Ionide) to solve it, we should pivot into seeing how we could personalize global.json ( older version for local development, fresh for CI). Which I have not yet figured out how, since the global.json is managed by an automated subscription and I do not see a way of passing in a different file depending on the environment.

[Martin521]

It's again the unreleased dotnet sdk missing. To me this happens when building from VS. Out of desperation I copy the local contents of .dotnet, that the build script downloaded, into system wide "C:\Program Files\dotnet" and it usually helps.

That's also what I ended up doing to make devcontainer work. There may be good reasons why standard dotnet installation is global and the sdk script installs local. But it is too bad that both insist that their way is the only one and neither offers an option to change the install location. And that they don't find each other's SDKs.