Msbuild Server
- 682 installs
- 4.9k repo stars
- Updated August 5, 2026
- dotnet/skills
msbuild-server is a Claude Code skill that shows developers how to enable MSBuild Server with MSBUILDUSESERVER=1 so repeated dotnet CLI builds cache evaluation results and match Visual Studio incremental build speed.
About
msbuild-server is a .NET & C# skill from dotnet/skills that explains how MSBuild Server improves command-line build performance for .NET projects. The skill activates when dotnet build incremental compiles are noticeably slower than Visual Studio and walks through setting MSBUILDUSESERVER=1 to keep a persistent server that caches MSBuild evaluation across CLI invocations. Developers reach for msbuild-server in local dev shells and CI jobs where small code changes still trigger full re-evaluation without a long-lived MSBuild process. The readme explicitly excludes IDE-based Visual Studio builds because Visual Studio already runs a persistent MSBuild host.
- MSBuild server lifecycle
- Incremental compile performance
- CI and local parity
- dotnet build integration
- Cache and node reuse
Msbuild Server by the numbers
- 682 all-time installs (skills.sh)
- Ranked #20 of 153 .NET & C# skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/dotnet/skills --skill msbuild-serverAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 682 |
|---|---|
| repo stars | ★ 4.9k |
| Last updated | August 5, 2026 |
| Repository | dotnet/skills ↗ |
Why are dotnet CLI builds slower than Visual Studio?
Speed up repeated .NET builds by configuring and using the MSBuild server for incremental compilation in local and CI workflows.
Who is it for?
.NET developers running frequent dotnet build from terminal or CI who see slow incremental compiles compared to Visual Studio IDE builds.
Skip if: Developers who only build inside Visual Studio IDE, which already uses a long-lived MSBuild process without MSBUILDUSESERVER.
When should I use this skill?
A developer reports slow incremental dotnet CLI builds or asks how to speed up command-line MSBuild evaluation caching.
What you get
MSBUILDUSESERVER=1 environment configuration, verified faster incremental dotnet build times, and CI-friendly server caching setup.
- MSBUILDUSESERVER=1 config
- Verified build timing improvement
Files
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
| Input | Required | Description |
|---|---|---|
| Shell context | No | The shell where the environment variable will be set (bash, PowerShell, or Windows persistent) |
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 1Step 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=1is set in the shell - [ ] Second sequential build is faster than the first
- [ ]
dotnet build-server shutdownfollowed by a rebuild confirms the server restarts cleanly
Common Pitfalls
| Pitfall | Solution |
|---|---|
| Expecting improvement in Visual Studio | VS already uses long-lived MSBuild nodes; the server adds no benefit |
| Build correctness issues after enabling | Run dotnet build-server shutdown to reset; if issues persist, disable the server |
| Server process using unexpected memory | The server persists in background; shut down with dotnet build-server shutdown when idle |
Related skills
Dotnet Best PracticesAutomatically verify that their.NET and C# code follows project-specific architecture, dependency injection, documentation, and localization conventions before committ13.9k37.5kNuget ManagerSafely add, remove, or update NuGet packages in.NET solutions without breaking project files or compatibility.12.9k37.5k
Dotnet PatternsGenerate idiomatic C# and.NET code that follows modern conventions for dependency injection, immutability, async patterns, and maintainable architecture.4.3k238k
Csharp DeveloperGenerate production-grade ASP.NET Core Minimal API patterns, repository layers, and endpoint scaffolding with correct dependency injection and OpenAPI metadata.3.6k10.9kDotnet Core ExpertGenerate production-grade.NET 8 code following clean architecture, minimal APIs, CQRS, and Entity Framework Core patterns.3.6k10.9kFsharp TestingGenerate, review, and debug high-quality tests for F#.NET applications using the modern testing stack.2.2k238kFAQ
What environment variable enables MSBuild Server?
msbuild-server documents setting MSBUILDUSESERVER=1 so the dotnet CLI reuses a persistent MSBuild Server process that caches evaluation results across repeated command-line builds.
Should msbuild-server be used for Visual Studio IDE builds?
msbuild-server should not be activated for IDE-based Visual Studio builds because Visual Studio already runs a long-lived MSBuild process that provides the same caching advantage.