SBE failing due to use of preview version of .NET

[ellahathaway]

This PR build targeting preview7 failed with the following error while building source build externals:

/vmr/.dotnet/sdk/9.0.100-preview.7.24357.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.RuntimeIdentifierInference.targets(326,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy [/vmr/src/source-build-externals/artifacts/sb/src/src/spectre-console/src/Spectre.Console/Spectre.Console.csproj::TargetFramework=net9.0]
      /vmr/.dotnet/sdk/9.0.100-preview.7.24357.2/Roslyn/Microsoft.CSharp.Core.targets(89,5): error MSB6006: "csc.dll" exited with code 139. [/vmr/src/source-build-externals/artifacts/sb/src/src/spectre-console/src/Spectre.Console/Spectre.Console.csproj::TargetFramework=net9.0]

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ellahathaway]

https://github.com/dotnet/dotnet/blob/76d842118ea686c6d31a842a392d53a4680b2f91/Directory.Build.props#L125 is set, investigating why it didn't propagate/maybe got overridden.

[ellahathaway]

I retried this build and it passed. Based on the error message, the build should have failed.

I also looked through the SBE binlog, and SuppressNETCoreSdkPreviewMessage is set to true for the specre-console project. This leads me to believe that the error is not actually related to us using a preview version of .NET. It's possible that this was caused by a race condition of sorts or an issue with the build agents.

@MichaelSimons - do you have any thoughts on this?

[MichaelSimons]

I don't think the build failure was caused by the preview SDK usage and the passing retry support this. Look at the inner binlog for the spectre.console project that failed. It has the following failure reported - CompilerServer: server failed - server rejected the request 'Compilation not allowed at this time' - Spectre.Console (net9.0)

[ellahathaway]

I don't think the build failure was caused by the preview SDK usage and the passing retry support this. Look at the inner binlog for the spectre.console project that failed. It has the following failure reported - CompilerServer: server failed - server rejected the request 'Compilation not allowed at this time' - Spectre.Console (net9.0)

Ah thanks! I missed that inner binlog. It looks like an issue with the tooling then.

cc @dotnet/roslyn

[jaredpar]

I suspect this is another manifestation of dotnet/dnceng#3305

There are two interesting parts in the binlog.

CompilerServer: server failed - server rejected the request 'Compilation not allowed at this time' - Spectre.Console (net9.0)

That message is given when a compilation request occurs while the compiler server is shutting down. That is not necessarily an error. The server could be timing out from lack of requests when this happens. Typically though when I see this I grep the binlog for $message Compiler Server: and see if there is an earlier compilation that had a real error that brought down the server. In this case there is only csc call so that is not the case. Most likely a graceful shutdown race from an earilier build on same machine.

/vmr/.dotnet/sdk/9.0.100-preview.7.24357.2/Roslyn/Microsoft.CSharp.Core.targets(89,5): error MSB6006: "csc.dll" exited with code 139. [/vmr/src/source-build-externals/artifacts/sb/src/src/spectre-console/src/Spectre.Console/Spectre.Console.csproj]

That is just a straight up compiler crash. Once the server rejected the request it fell back to direct invoke of csc.dll and that crashed. Unfortunately Linux doesn't always put a call stack in the build file so we can't see what is happening. But given that one manifestation of dnceng 3305 is a straight crash we should likely wait for that investigation to resolve.

[ellahathaway]

@jaredpar - Thanks for the in depth explanation! It sounds like this is likely caused by dotnet/dnceng#3305, so I'm going to close this issue in favor of dotnet/dnceng#3305.

[jaredpar]

Note: may also be dotnet/runtime#104123

There are two investigations on going right now which have this symptom.