Before optimizing a build, you need a baseline. Without measurements, optimization is guesswork. This skill covers how to establish baselines and apply systematic optimization techniques.
\nRelated skills:
\nbuild-perf-diagnostics — binlog-based bottleneck identificationincremental-build — Inputs/Outputs and up-to-date checksbuild-parallelism — parallel and graph build tuningeval-performance — glob and import chain optimizationMeasure three scenarios to understand where time is spent:
\nNo previous build output exists. Measures the full end-to-end time including restore, compilation, and all targets.
\n# Clean everything first\ndotnet clean\n# Remove bin/obj to truly start fresh\nGet-ChildItem -Recurse -Directory -Include bin,obj | Remove-Item -Recurse -Force\n# OR on Linux/macOS:\n# find . -type d \\( -name bin -o -name obj \\) -exec rm -rf {} +\n\n# Measure cold build\ndotnet build /bl:cold-build.binlog -m\nBuild output exists, some files have changed. Measures how well incremental build works.
\n# Build once to populate outputs\ndotnet build -m\n\n# Make a small change (touch one .cs file)\n# Then rebuild\ndotnet build /bl:warm-build.binlog -m\nBuild output exists, nothing has changed. This should be nearly instant. If it's slow, incremental build is broken.
\n# Build once to populate outputs\ndotnet build -m\n\n# Rebuild immediately without changes\ndotnet build /bl:noop-build.binlog -m\n| Scenario | \nExpected Behavior | \n
|---|---|
| Cold build | \nFull compilation, all targets run. This is your absolute baseline | \n
| Warm build | \nOnly changed projects recompile. Time proportional to change scope | \n
| No-op build | \n< 5 seconds for small repos, < 30 seconds for large repos. All compilation targets should report \"Skipping target — all outputs up-to-date\" | \n
Red flags:
\nincremental-build skill)Record baselines in a structured way before and after optimization:
\n| Scenario | Before | After | Improvement |\n|-------------|---------|---------|-------------|\n| Cold build | 2m 15s | | |\n| Warm build | 1m 40s | | |\n| No-op build | 45s | | |\nThe MSBuild server keeps the build process alive between invocations, avoiding JIT compilation and assembly loading overhead on every build.
\n# Enabled by default in .NET 8+ but can be forced\ndotnet build /p:UseSharedCompilation=true\nThe MSBuild server is started automatically and reused across builds. The compiler server (VBCSCompiler / dotnet build-server) is separate but complementary.
# Check if the server is running\ndotnet build-server status\n\n# Shut down all build servers (useful when debugging)\ndotnet build-server shutdown\nRestart after:
\ndotnet build-server shutdown\ndotnet build\nThe UseArtifactsOutput feature (introduced in .NET 8) changes the output directory structure to avoid bin/obj clash issues and enable better caching.
<!-- Directory.Build.props -->\n<PropertyGroup>\n <UseArtifactsOutput>true</UseArtifactsOutput>\n</PropertyGroup>\n# Traditional layout (before)\nsrc/\n MyLib/\n bin/Debug/net8.0/MyLib.dll\n obj/Debug/net8.0/...\n MyApp/\n bin/Debug/net8.0/MyApp.dll\n\n# Artifacts layout (after)\nartifacts/\n bin/MyLib/debug/MyLib.dll\n bin/MyApp/debug/MyApp.dll\n obj/MyLib/debug/...\n obj/MyApp/debug/...\nartifacts/ directory to cache/restore in CIartifacts/<!-- Change the artifacts root -->\n<PropertyGroup>\n <ArtifactsPath>$(MSBuildThisFileDirectory)output</ArtifactsPath>\n</PropertyGroup>\nDeterministic builds produce byte-for-byte identical output given the same inputs. This is essential for build caching and reproducibility.
\n<!-- Directory.Build.props -->\n<PropertyGroup>\n <!-- Enabled by default in .NET SDK projects since SDK 2.0+ -->\n <Deterministic>true</Deterministic>\n\n <!-- For full reproducibility, also set: -->\n <ContinuousIntegrationBuild Condition=\"'$(CI)' == 'true'\">true</ContinuousIntegrationBuild>\n</PropertyGroup>\nReducing unnecessary project references shortens the critical path and reduces what gets built.
\n# Visualize the dependency graph\ndotnet build /bl:graph.binlog\n\n# In the binlog, check project references and build times\n# Look for projects that are referenced but could be trimmed\n<!-- BAD: Utils is already referenced transitively via Core -->\n<ItemGroup>\n <ProjectReference Include=\"..\\Core\\Core.csproj\" />\n <ProjectReference Include=\"..\\Utils\\Utils.csproj\" />\n</ItemGroup>\n\n<!-- GOOD: Let transitive references flow automatically -->\n<ItemGroup>\n <ProjectReference Include=\"..\\Core\\Core.csproj\" />\n</ItemGroup>\nWhen you need a project to build before yours but don't need its assembly output:
\n<!-- Only ensures build order, doesn't reference the output assembly -->\n<ProjectReference Include=\"..\\CodeGen\\CodeGen.csproj\"\n ReferenceOutputAssembly=\"false\" />\nWhen a dependency is an internal implementation detail that shouldn't flow to consumers:
\n<!-- Don't expose this dependency transitively -->\n<ProjectReference Include=\"..\\InternalHelpers\\InternalHelpers.csproj\"\n PrivateAssets=\"all\" />\nFor explicit-only dependency management (extreme measure for very large repos):
\n<PropertyGroup>\n <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>\n</PropertyGroup>\nCaution: This requires all dependencies to be listed explicitly. Only use in large repos where transitive closure is causing excessive rebuilds.
\n/graph)Static graph mode evaluates the entire project graph before building, enabling better scheduling and isolation.
\n# Single invocation\ndotnet build /graph\n\n# With binary log for analysis\ndotnet build /graph /bl:graph-build.binlog\n| Scenario | \nRecommendation | \n
|---|---|
| Large multi-project solution (20+ projects) | \n✅ Try /graph — may see significant parallelism gains | \n
| Small solution (< 5 projects) | \n❌ Overhead of graph evaluation outweighs benefits | \n
| CI builds | \n✅ Graph builds are more predictable and parallelizable | \n
| Local development | \n⚠️ Test both — may or may not help depending on project structure | \n
Graph build requires that all ProjectReference items are statically determinable (no dynamic references computed in targets). If graph build fails:
error MSB4260: Project reference \"...\" could not be resolved with static graph.\nFix: Ensure all ProjectReference items are declared in <ItemGroup> outside of targets (not dynamically computed inside <Target> blocks).
# Use all available cores (default in dotnet build)\ndotnet build -m\n\n# Specify explicit core count (useful for CI with shared agents)\ndotnet build -m:4\n\n# MSBuild.exe syntax\nmsbuild /m:8 MySolution.sln\nIn a binlog, look for:
\nUse grep 'Target Performance Summary' -A 30 full.log in binlog analysis to see build node utilization.
The critical path is the longest chain of dependent projects. To shorten it:
\nReferenceOutputAssembly=\"false\" for build-order-only dependencies# In CI, restore once then build without restore\ndotnet restore\ndotnet build --no-restore -m\ndotnet test --no-build\n# Skip building documentation\ndotnet build /p:GenerateDocumentationFile=false\n\n# Skip analyzers during development (not for CI!)\ndotnet build /p:RunAnalyzers=false\n# Build only the project you're working on (and its dependencies)\ndotnet build src/MyApp/MyApp.csproj\n\n# Don't build the entire solution if you only need one project\nAlways start with a binlog:
\ndotnet build /bl:perf.binlog -m\nThen use the build-perf-diagnostics skill and binlog tools for systematic bottleneck identification.
Is your no-op build slow (> 10s per project)?\n├── YES → See `incremental-build` skill (fix Inputs/Outputs)\n└── NO\n Is your cold build slow?\n ├── YES\n │ Is restore slow?\n │ ├── YES → Optimize NuGet restore (use lock files, configure local cache)\n │ └── NO\n │ Is compilation slow?\n │ ├── YES\n │ │ Are analyzers/generators slow?\n │ │ ├── YES → See `build-perf-diagnostics` skill\n │ │ └── NO → Check parallelism, graph build, critical path (this skill + `build-parallelism`)\n │ └── NO → Check custom targets (binlog analysis via `build-perf-diagnostics`)\n └── NO\n Is your warm build slow?\n ├── YES → Projects rebuilding unnecessarily → check `incremental-build` skill\n └── NO → Build is healthy! Consider graph build or UseArtifactsOutput for further gains\n