build-perf-baseline

Measure three scenarios: a cold build after deleting bin/obj folders, a warm build after changing one file, and a no-op build with no changes. Use dotnet build with the /bl flag to capture binary logs for each scenario.

Start by recording a baseline, then enable MSBuild Server, UseArtifactsOutput, and static graph builds with /graph. Trim redundant ProjectReferences, separate restore from build, and tune parallelism with the -m flag.

A no-op build should finish in under 5 seconds for small repos and under 30 seconds for large repos, with all compilation targets skipped as up-to-date. A no-op build over 30 seconds indicates broken incremental build.

Use static graph builds for large solutions with 20 or more projects and in CI, where upfront graph evaluation improves scheduling and parallelism. For solutions under 5 projects, the graph evaluation overhead usually outweighs the benefits.

Full recompilation on warm builds usually means the project dependency chain forces downstream rebuilds. Remove redundant transitive ProjectReferences, use ReferenceOutputAssembly="false" for build-order-only dependencies, and check incremental build Inputs/Outputs.

No, these techniques are specific to MSBuild and the dotnet CLI, including features like MSBuild Server, UseArtifactsOutput, and static graph builds. Other build systems like Bazel or Gradle require different tooling.