/msbuild-server
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
$ npx -y skills add dotnet/skills --skill msbuild-server --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/msbuild-server
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
msbuild-server.SKILL.mdname: 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
| 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 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
| 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 |
Read more
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
| 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 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
| 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 |
This repository contains the .NET team's curated set of core skills and custom agents for coding agents. For information about the Agent Skills standard, see agentskills.io. 📊 Dashboard - Accuracy and efficiency scoring trends for contained plugins (
Repo: dotnet/skills
Other skills on dotnet-skills.
- /csharp-scripts
Run file-based C# apps with the .NET CLI when the user explicitly wants C#/.NET code without creating a project. Use for C# language/API experiments, one-file C# apps, small multi-file C# apps composed with `#:include`/`#:exclude`, or C# file-based apps linked with `#:ref`. Do
Open skill - /dotnet-pinvoke
Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging
Open skill - /nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to
Open skill - /technology-selection
Guides technology selection and implementation of AI and ML features in .NET 8+ applications using ML.NET, Microsoft.Extensions.AI (MEAI), Microsoft Agent Framework (MAF), GitHub Copilot SDK, ONNX Runtime, and OllamaSharp. Covers the full spectrum from classic ML through modern
Open skill - /configuring-opentelemetry-dotnet
Configure OpenTelemetry distributed tracing, metrics, and logging in ASP.NET Core using the .NET OpenTelemetry SDK. Use when adding observability, setting up OTLP exporters, creating custom metrics/spans, or troubleshooting distributed trace correlation.
Open skill - /convert-blazor-server-to-webapp
Guides conversion of a pre-.NET 8 Blazor Server app into a .NET 8+ Blazor Web App. USE FOR: migrating apps that use AddServerSideBlazor and MapBlazorHub to the AddRazorComponents/MapRazorComponents model, converting _Host.cshtml to an App.razor root component, replacing
Open skill

