msbuild-server

name: msbuild-server description: "Guide for using MSBuild Server to improve CLI build performance. Activate when developers report slow incremental builds from the command line, or when CLI builds are noticeably slower than IDE builds. Covers MSBUILDUSESERVER=1 environment variable for persistent server-based caching. Do not activate for IDE-based builds (Visual Studio already uses a long-lived process)." license: MIT

MSBuild Server for CLI Caching

Use the MSBuild Server to cache evaluation results across CLI builds, matching the performance advantage Visual Studio gets from its long-lived MSBuild process.

When to Use

• Small incremental builds from CLI (dotnet build) are slower than expected
• Developers notice that VS builds are faster than CLI builds for the same project
• CI agents run many sequential builds of the same repo

When Not to Use

• IDE-based builds (Visual Studio already uses a long-lived MSBuild process)
• One-off builds where cold-start overhead is acceptable
• Build correctness issues are suspected (disable the server to isolate the problem)

Inputs

Workflow

Step 1: Confirm CLI context

Verify the developer is building from the command line (dotnet build), not from Visual Studio or another IDE. The MSBuild Server provides no benefit inside an IDE.

Step 2: Set the environment variable

# Bash / CI
export MSBUILDUSESERVER=1

# PowerShell
$env:MSBUILDUSESERVER = "1"

# Windows (persistent)
setx MSBUILDUSESERVER 1

Step 3: Validate improvement

Run two sequential builds of the same project and compare times:

1. First build (cold): dotnet build -- server starts, no cache benefit
2. Second build (warm): dotnet build -- should be noticeably faster

The most noticeable improvement is in repos with many projects or complex Directory.Build.props chains.

Validation

• MSBUILDUSESERVER=1 is set in the shell
• Second sequential build is faster than the first
• dotnet build-server shutdown followed by a rebuild confirms the server restarts cleanly

Common Pitfalls