Can't build FCS in main

[auduchinok]

When trying to build FCS, this is the error I'm getting:

eugene@Eugenes-Lab:fsharp [main]$ dotnet build FSharp.Compiler.Service.sln
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'build' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      The .NET SDK could not be found, please run ./eng/common/dotnet.sh.

I do have the latest .NET 10 preview installed.
Apparently, global.json specifies an unreleased .NET SDK version since yesterday. Can this be reverted? It's not possible to build the project in main anymore.

Can we somehow prevent this from happening in future?
Can we return to requiring a release .NET SDK version only, at least for building FCS? It should be possible to have a separate global.json and CI would save us from a situation like this.

[Martin521]

The same happened with preview 6. We had a discussion in the Compiler channel of the F# Slack at the time.
See also #18715.
A workaround is to first run the build script, which will install the unreleased SDK.
But I agree that a way to build FCS with a publically released SDK is desirable.

[T-Gro]

Plain builds in the CI are doing this:
script: ./eng/common/dotnet.sh build ./FSharp.Compiler.Service.sln

Which is doing a plain build, without building the proto compiler (so runs faster than running the full build.sh script).
The dotnet.sh script checks global.json, and downloads the right SDK based on it.

Once you have the .dotnet folder created and your globally installed SDK is at least v10p3, it should also pick up the new property of global.json that specifies the local path to search (on top of searching in the global locations). i.e. after the initial download, plain dotnet command should work as well.

We do want to build with latest tooling to spot regressions earlier, but you are right we do not need to enforce this on every contributor.
The goal could be along the lines: If the CI or anyone is going to download an SDK, it should be the one specified. But please do not shout if it's not installed, the same major is fine.

[T-Gro]

@baronfel :
Is there a recommended practice for aiming to use the highest SDK if one is going to be downloaded (CI, build scripts), but still not failing if it isn't exactly met?
Along the lines of rollForward, but also allowing backward to latestMajor.

[auduchinok]

A workaround is to first run the build script, which will install the unreleased SDK.

The FCS solution was added specifically to never use the build scripts and to use the machine toolchain which we always tried to keep the stable release one.

[auduchinok]

@T-Gro @vzarytovskii This has happened again. global.json refers to a non-existent SDK. Can we please do something about it?

[vzarytovskii]

@T-Gro @vzarytovskii This has happened again. global.json refers to a non-existent SDK. Can we please do something about it?

I don't know why was the change made, so I'm of no help here likely.

[auduchinok]

The SDK was promoted in f1ca26a to rc1 while the latest available one is preview 7.

Given that we've always aimed to use released stable versions for FCS solution, the use of an unreleased .NET SDK is even more concerning than using the previews themselves.

Please, let's prevent this from happening. It's becoming painful to contribute to FCS as an external contributor.

[edgarfgp]

Yeah this seems unnecessary contributor pain.

[vzarytovskii]

The SDK was promoted in f1ca26a to rc1 while the latest available one is preview 7.

Since it's automated, it seems, there was a switch for SDK from latest released to just latest. Don't know why was that. My guess is that folks wanted to test newest changes as soon as they get in (pass some quality gates).