.NET 11 Preview 7 Parallelism Breaks SBOM Generation

[christophwille]

Issue Description

We traced the problem in comment icsharpcode/ILSpy#3981 (comment)

The actual build output (we are using Microsoft.Sbom.Targets):

Warning: Unknown error while running CD scan: System.ObjectDisposedException: Cannot write to a closed TextWriter.
   at Microsoft.Build.Experimental.OutOfProcServerNode.RedirectConsoleWriter.Write(String value)
   at System.IO.TextWriter.SyncTextWriter.Write(String value)
   at Spectre.Console.AnsiConsoleBackend.Write(IRenderable renderable) in /_/src/Spectre.Console/Internal/Backends/Ansi/AnsiConsoleBackend.cs:line 33
   at Spectre.Console.AnsiConsoleFacade.Write(IRenderable renderable) in /_/src/Spectre.Console/Internal/Backends/AnsiConsoleFacade.cs:line 40
   at Spectre.Console.AnsiConsole.Write(IRenderable renderable) in /_/src/Spectre.Console/AnsiConsole.Rendering.cs:line 29
   at Microsoft.ComponentDetection.Orchestrator.Services.DetectorProcessingService.LogTabularOutput(ConcurrentDictionary`2 providerElapsedTime, Double totalElapsedTime)
   at Microsoft.ComponentDetection.Orchestrator.Services.DetectorProcessingService.ProcessDetectorsAsync(ScanSettings settings, IEnumerable`1 detectors, DetectorRestrictions detectorRestrictions, CancellationToken cancellationToken)
   at Microsoft.ComponentDetection.Orchestrator.Services.ScanExecutionService.ExecuteScanAsync(ScanSettings settings, CancellationToken cancellationToken)
   at Microsoft.ComponentDetection.Orchestrator.Commands.ScanCommand.ExecuteScanCommandAsync(ScanSettings settings, CancellationToken cancellationToken)
   at Microsoft.Sbom.Api.Utils.ComponentDetector.ScanAsync(ScanSettings args)
   at Microsoft.Sbom.Api.Utils.ComponentDetectorCachedExecutor.ScanAsync(ScanSettings args)
   at Microsoft.Sbom.Api.Executors.ComponentDetectionBaseWalker.<>c__DisplayClass11_0.<<GetComponents>g__Scan|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.Sbom.Api.Executors.ComponentDetectionBaseWalker.<>c__DisplayClass11_0.<<GetComponents>b__1>d.MoveNext()
Warning: There were no packages detected during the generation workflow.

The problem didn't exist in preview6, only started showing up with preview7. @baronfel

Steps to Reproduce

It is reproducible when the ENV var is not set and you pack multiple packages.

Expected Behavior

Continue to work like it did before in preview6.

Actual Behavior

Packages didn't contain SBOM.

Analysis

Setting the ENV var disabling parallelism fixed the problem

Versions & Configurations

.NET 11 Preview 7

[KalleOlaviNiemitalo]

I wonder if multithreaded MSBuild should eagerly make Console.Out refer to a bridge that would feed the output to IAsyncLocal<ILogger>. Perhaps not; that would invite task developers to use Console.Out but would disappoint them if the task starts a child process that then writes to its standard output.

[ViktorHofer]

MSBuild triage: @baronfel you did an internal change related to this. Would you mind sharing an update here? Thanks

[baronfel]

I've got a PR out at microsoft/sbom-tool#1529 to fix this, but am working with the team to schedule review, merge, and release.

[baronfel]

We're also looking at a workaround of changing the 'default' output streams (stdout/stderr) as writeable-but-ignored streams instead of streams that are not writable at all. This would allow incorrectly-authored Tasks to at least not crash, though their data would be lost. We'll start with this and look at telemetry/storage/reporting of the Tasks that end up hitting this mechanism as a follow-up.

[JanProvaznik]

Verified fixed in main by #14850.

I reproduced this against two bootstrap builds from the same main tree (7a10a3b778) — one as-is, one with #14850 reverted — issuing two Pack requests through a reused MSBuild Server:

Build	Run	Server PID	ObjectDisposedException	"no packages detected"	Packages in SBOM
#14850 reverted	1	6228	0	0	7
#14850 reverted	2	6228 (reused)	3	1	1
main	1	25744	0	0	7
main	2	25744 (reused)	0	0	7

The reverted build reproduced the exact stack reported here and silently dropped Newtonsoft.Json from the manifest while still exiting 0. Current main preserves all 7 packages on the second, server-reused request.

Root cause: MSBuild Server disposes its request-scoped RedirectConsoleWriter at the end of each build, but Spectre.Console (reached via Component Detection) caches the first request's Console.Out in a process-wide singleton. #14850 makes the writer discard post-dispose writes instead of throwing.

Two caveats:

• This is the MSBuild-side mitigation only — Fix ObjectDisposedException in GenerateSbom Task under MSBuild Server microsoft/sbom-tool#1529 is the proper fix for the caching itself.
• The fix is on main only; no vs18.x branch contains it, so it reaches users in the .NET 11 GA band. On preview 7 / rc1, DOTNET_CLI_USE_MSBUILD_SERVER=false remains the workaround.

Repro: net10.0 classlib with Microsoft.Sbom.Targets 4.1.5 + Newtonsoft.Json 13.0.3 and GenerateSBOM=true, packed twice with MSBUILDUSESERVER=1 after dotnet build-server shutdown.