Fix missing .NET 11 framework build issue

[xperiandri]

Description

Fixes .NET 11 SDK/runtime resolution during local and CI builds. Bootstrap apphosts (fsc, fsi, testhost, etc.) resolve the runtime via DOTNET_ROOT/multi-level lookup rather than PATH, so when a machine also has other .NET installations, the apphost could pick up an unexpected or missing runtime instead of the repo-local .dotnet install, causing build/test failures on machines where the .NET 11 framework isn't globally installed.

This change:

• Prefers the repo-local .dotnet host in FSharpBuild.Directory.Build.props so the compiler host and bootstrap runtime come from the same install.
• Sets DOTNET_ROOT and DOTNET_MULTILEVEL_LOOKUP=0 in eng/Build.ps1, eng/build-utils.ps1, eng/build.sh, and eng/test-determinism.ps1 right after InitializeDotNetCli, so every apphost spawned during bootstrap/build/test resolves the correct SDK/runtime instead of falling back to a machine-wide lookup.

Fixes # (issue, if applicable)

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated:

  Entry added to docs/release-notes/.FSharp.Compiler.Service/11.0.100.md:

  • Fix missing .NET 11 framework build support by preferring the repo-local .dotnet host and setting DOTNET_ROOT with DOTNET_MULTILEVEL_LOOKUP=0 for bootstrap toolchains, so apphosts and test hosts resolve the correct SDK/runtime instead of a stale machine-wide installation.

[github-actions]

✅ No release notes required

[github-actions]

🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Bootstrap
Affects-Build-Infra: modifies Directory.Build.props and eng/*.ps1/sh build scripts
Affects-Bootstrap: changes bootstrap compiler path resolution logic

Generated by PR Tooling Safety Check · opus46 3.8M · ◷

[T-Gro]

Trimmed this way down. start-vs-FsharpSln.cmd already exports DOTNET_ROOT at the repo-local .dotnet, so launching VS through it resolves the net11 preview runtime without any MSBuild redirect. The FSharpBuild.Directory.Build.props block was re-implementing what Microsoft.FSharp.NetSdk.props already does, and DOTNET_MULTILEVEL_LOOKUP=0 is a no-op on .NET 7+ hosts. What's left is just exporting DOTNET_ROOT in build.sh and build-utils.ps1 for parity with Build.ps1, which already set it.

[xperiandri]

My issue was building the solution in VS

[T-Gro]

But are you launching VS via the launch script?

[xperiandri]

Ah, no. Just as a regular from Start menu.
So I should do that from the cmd 😮
Not so obvious 🙂