C# Dev Kit fastbuild takes 6× longer than a full CLI rebuild after project/package configuration changes #9870

Summary

C# Dev Kit's Solution Explorer Build took approximately 8 minutes 10 seconds
after project/package configuration changes. A full CLI rebuild of the same
solution, including restore, took 80.7 seconds.

Subsequent unchanged Solution Explorer builds are extremely fast—305 ms—so
the issue appears specific to the cache-invalidated build path.

Environment

• OS: Windows x64
• C# Dev Kit: 11.3.30
• VS Code version: [fill in]
• C# extension version: [fill in]
• SDK selected in global.json: 11.0.100-rc.2.26504.105
• Solution format: .slnx
• Build configuration: Debug / Any CPU
• Solution contains 76 projects, including ASP.NET Core/Blazor applications,
  Azure Functions, shared libraries, tools, and test projects.
• Central Package Management using Directory.Packages.props.
• dotnet.build.useFastBuild is not overridden, so it uses the default of true.

Observed sequence

1. Project files and Directory.Packages.props had been modified.
2. In Solution Explorer, I right-clicked the solution and selected Build.
3. C# Dev Kit invoked fastbuild.exe.
4. The log reported that restore was needed and that projects required builds
   because structure inputs had changed.
5. The operation took 490.219 seconds and reported 76 built, 0 skipped.
6. A subsequent unchanged Solution Explorer build took only 305 ms.

I have not yet isolated a minimal change that reliably reproduces the slow
cache-invalidated build.

Actual behaviour

The Solution Explorer Build command was:

fastbuild.exe \ecoDriverWeb.slnx -p:GenerateFullPaths=true -p:Configuration=Debug -p:Platform="Any CPU"

The log began with a restore-needed message identifying a project file newer
than project.assets.json, followed by:

fastbuild: restoring...

Projects were then reported as needing builds, for example:

fastbuild: CosmosMigrator: building (structure input changed: ......\Directory.Packages.props)
fastbuild: ecoDriverCore.Shared: building (structure input changed: ecoDriverCore.Shared.csproj)

The output repeatedly showed an individual project build followed by its own
"Build succeeded", warning/error counts, and "Time Elapsed" summary, before
the next project was reported.

In the terminal, this appeared as build/pause/build/pause rather than the
much faster overall progress seen with the CLI.

The final summary was:

fastbuild: done in 490219 ms: 76 built, 0 skipped.

All project build summaries reported zero warnings and zero errors.

CLI comparison

A normal solution build excluding restore completed in 17.1 seconds:

dotnet build .\ecoDriverWeb.slnx --no-restore -m -tl:on

To compare against a more substantial workload, I then ran a full solution
rebuild with implicit restore, matching Debug / Any CPU:

dotnet build .\ecoDriverWeb.slnx -t:Rebuild -m -tl:on -p:Configuration=Debug '-p:Platform=Any CPU'

This completed in 80.7 seconds.

The slow fastbuild run was approximately 6.1 times slower than the full CLI
rebuild.

Expected behaviour

Building after project/package configuration changes should have performance
reasonably comparable to a normal CLI build of the same solution.

Fastbuild's unchanged-build performance is excellent, but the observed
cache-invalidated build was substantially slower than even a full CLI rebuild.

Investigation request

Could you investigate the build path used when structure changes invalidate
fastbuild's cache?

The separate per-project build summaries suggest that per-project invocation
overhead or limited parallel scheduling might be relevant, but I have not
confirmed either as the cause.

Version:

C# Dev Kit pre-release 11.3.30
.NET 11 rc2