`MSBuildCracker` does NOT respect `global.json` (Fable 4 + 5)

[cr3wdayt5p]

Hi

I am looking to upgrade our setup from Fable 4 + .NET 8 to Fable 5 + .NET 10, and in this process I got results that I could not easily explain.

But I have now pinned down the reason for some of the confusing results:
MSBuildCracker does NOT respect global.json (and hence does NOT use the SDK version specified for the repo)

This can result in a project failing to build with dotnet build but not with dotnet fable (or the other way around).

This is confusing when trying to investigate issues related to version upgrades 😊

This is a breaking change from the legacy cracker in Fable 4 which does respect global.json.

Steps to verify

1. Install both .NET SDK 8 and .NET SDK 10 on the machine (verify with dotnet --info).
2. Fix the SDK version to .NET 8 in global.json in your repo, e.g.: {"sdk": {"version": "8.0.416","rollForward": "latestFeature"}}
3. Set the TargetFramework to net42.0 (or some other non-released version) in your project file. This is just to provoke an error in the restore process.
4. Run dotnet build. Observe that the error is produced by SDK 8, e.g.: /usr/local/share/dotnet/sdk/8.0.416/Sdks/Microsoft.NET.Sdk/....
5. Run dotnet fable. Observe that the error is produced by SDK 10, e.g.: /usr/local/share/dotnet/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/....

This affects both Fable 4.27.0 (using --test:MSBuildCracker) and Fable 5.0.0-alpha.14.

Where to look
It is likely caused by this line: https://github.com/fable-compiler/Fable/blob/main/src/Fable.Compiler/MSBuildCrackerResolver.fs#L35

psi.WorkingDirectory <- Environment.GetFolderPath(Environment.SpecialFolder.UserProfile)

But there is no comment in the surrounding code explaining why dotnet msbuild should run in user profile directory rather than in the directory in where dotnet fable was called from (and hence would pick up the correct global.json file).

Machine Info

• OS: macOS 26.1
• .NET SDK: 8.0.416 and 10.0.100
• Fable: 4.27.0 and 5.0.0-alpha.14

[MangelMaxime]

What is the error you are getting?

If I remember correctly, the reason why MSBuildCracker is invoked from Environment.SpecialFolder.UserProfile was because dotnet msbuild is available only from .NET 8+.

This allow us to use dotnet msbuild even if your project is targeting net6.0 (forced by global.json). We only use dotnet msbuild to extract the information we need like the target framework, files/projects to compile, etc.

So it should not affect the compilation process and give the same result for dotnet build and dotnet fable.

[cr3wdayt5p]

The overall problem is non-reproducible builds, i.e. the build result depends on the arbitrary .NET SDK(s) installed on the machine rather than being deterministic (based on global.json).

In particular I was investigating an issue with a change in the standard library for .NET where System.TimeSpan.FromMilliseconds 100 is no longer allowed. It should now be either a double or int64. That is trivial to fix. But during the investigation of this I got these inconsistent errors.

I had by mistake pinned to SDK 8 with global.json and set TFM to net10.0. This should naturally give an error like ".NET 10 is not supported by SDK 8" (like it did with dotnet build). But with Fable this was not the case – it kept on trying to build and giving me the error for System.TimeSpan.FromMilliseconds despite the fact that it should have been constrained by global.json to NOT include references to the standard library for .NET 10 (not available with SDK 8).

If another developer or CI did not have same SDK(s) installed then we would have had different build errors, i.e. non-reproducible builds.

I don't think it is worth sacrificing reproducible builds for the sake of backwards compatibility with pre-net8.0 projects – at least not for Fable 5 (which is allowed to be a breaking change).

This inconsistency between dotnet build and dotnet fable is making it more confusing to upgrade from Fable 4 + .NET 8 to Fable 5 + .NET 10 since it is unclear what versions Fable is actually respecting (SDK version, TFM, language version, etc.). This will likely be a problem again for new versions of .NET and Fable in the future.

Suggested solution
I think we should default to respecting global.json (let dotnet msbuild run within the repo) and be consistent with the .NET ecosystem in general to support reproducible builds.

And then optionally support the "old target" use case by an explicit extra flag, e.g. --resolve-with-user-available-sdk-version {version} (or some better name 😊).

[MangelMaxime]

I had by mistake pinned to SDK 8 with global.json and set TFM to net10.0. This should naturally give an error like ".NET 10 is not supported by SDK 8" (like it did with dotnet build). But with Fable this was not the case – it kept on trying to build and giving me the error for System.TimeSpan.FromMilliseconds despite the fact that it should have been constrained by global.json to NOT include references to the standard library for .NET 10 (not available with SDK 8).

I was not aware of this issue, I thought that we will be ok with the current setup.

But indeed, if there are subtle bugs like this one we should make Fable run msbuild from the CWD. We should probably however, either detect if dotnet msbuild is missing or parse the dotnet --version to indicate to the user that they need at least .NET 8 for it to work.

[cr3wdayt5p]

That seems like a reasonable approach.

According the docs on dotnet msbuild it appears that it has been available since .NET 6. But maybe MSBuildCracker needs features only available in newer versions?

Also regarding the use case for "old target" I don't think that should be a problem. I am no expert on this at all, but I think that it should only be the TFM that should matter for compatibility with older targets. Newer SDKs should be able to build against older targets. It should NOT be needed to pin an old SDK using global.json, e.g. 6.0.428, just to be able use TFM net6.0.

Newer SDKs may throw a warning if you trying to build against older targets. But there is even a built-in property to suppress this NETSDK1138 warning with <CheckEolTargetFramework>false</CheckEolTargetFramework>.

[cr3wdayt5p]

@MangelMaxime Something like #4261 can solve this issue and make the cracking reproducible.

[MangelMaxime]

Regarding my last comment, Fable 5 targets net8.0 and because of that we can't install it when global.json has 6.0.x configured.

Meaning that we can assume that the version of dotnet msbuild is always available here.

For Fable 4, more testing is needed to verify if the fix proposed is enough or if we do need to capture and error to help the user.

[cr3wdayt5p]

For Fable 4, more testing is needed to verify if the fix proposed is enough or if we do need to capture and error to help the user.

Sure, better error messages are always a good thing. But this fix not does change the requirement for .NET SDK 8 for MSBuildCracker it just makes it consistent with other .NET tooling (using the .NET SDK available from the current directory – either pinned by global.json or not).

So, in the case of a project with no global.json the behavior will be identical.
With the fix in place the behavior is changed for projects with a global.json and the SDK pinned to a non-compatible SDK version (while a compatible SDK is available the user profile dir). But the error message here would be the same as if no global.json and only a non-compatible SDK available.

[MangelMaxime]

I understand, I also want to make sure we do report an error to the user.

[cr3wdayt5p]

@MangelMaxime You can consider merging the small fix in #4262 such that work on this issue is not hindered by this minor bug.

[cr3wdayt5p]

If I remember correctly, the reason why MSBuildCracker is invoked from Environment.SpecialFolder.UserProfile was because dotnet msbuild is available only from .NET 8+.

@MangelMaxime It appears that dotnet msbuild has been available for a while. But do you know if it is a specific version that is needed?

docker run --rm mcr.microsoft.com/dotnet/sdk:5.0 dotnet msbuild --version

Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

16.11.2.50704

docker run --rm mcr.microsoft.com/dotnet/sdk:6.0 dotnet msbuild --version

MSBuild version 17.3.4+a400405ba for .NET
17.3.4.17815

docker run --rm mcr.microsoft.com/dotnet/sdk:7.0 dotnet msbuild --version

MSBuild version 17.7.6+77d58ec69 for .NET
17.7.6.17813

docker run --rm mcr.microsoft.com/dotnet/sdk:8.0 dotnet msbuild --version

MSBuild version 17.11.48+02bf66295 for .NET
17.11.48.46605

[MangelMaxime]

I can't find the conversation where it was mentioned.

But it seems like we need MSBuild 16.8+, which seems to have been introduced in .NET SDK 5.0 and have better compatibility in .NET SDK 6.0.

To move forward, I will try to make Fable 4 use the local version of MSBuild in .NET 6 and see how it goes. Fable targetting .NET we can't install it/run it with .NET 5 so it should prevent using it with an invalid version.