msbuild-server

$npx mdskill add microsoft/testfx/msbuild-server

Enable MSBuild Server for faster CLI builds

  • Verify CLI build context to ensure benefits of MSBuild Server.
  • Deploys MSBUILDUSESERVER=1 environment variable for server-based caching.
  • Decides when to use based on developer-reported slow incremental builds from CLI.
  • Delivers improved performance by leveraging persistent MSBuild cache across builds.

SKILL.md

.github/skills/msbuild-serverView on GitHub ↗
---
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
# 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 |

More from microsoft/testfx

SkillDescription
assertion-qualityAnalyze assertion quality, depth, variety, and false confidence in existing tests. ALWAYS USE when asked about weak, shallow, trivial, always-true, self-referential, assertion-free, presence/truthiness-only, or insufficiently diverse assertions, including MSTest, Jest, pytest, and Go. DO NOT USE for direct fixes: writing-mstest-tests owns supplied MSTest assertions; code-testing owns new cases. Use test-gap-analysis when asked whether tests would catch a production change, and test-anti-patterns for general severity-ranked audits.
behavior-preserving-refactorPreserve observable behavior when splitting files, moving members, consolidating helpers, or simplifying TestFx code. Use for structural refactors and file-diet implementation; inventory baseline semantics and consumers, then run focused equivalence checks.
binlog-failure-analysisDiagnose existing MSBuild .binlog failures with MCP/replay; not log capture or non-MSBuild failures.
binlog-generationCapture and verify unique MSBuild binlogs, quoting '-bl:{}' in PowerShell; not analysis of existing logs.
build-parallelismAnalyze an MSBuild solution, solution filter, or Build.proj that schedules multiple project files. USE FOR: measured idle worker nodes, `-m` that does not scale, a serial ProjectReference critical path, graph builds, or an MSBuild task that builds a Projects list. Requires at least two distinct project files whose scheduling or throughput must be analyzed. DO NOT USE for non-MSBuild build systems.
build-perf-baselineMeasure repeatable cold/changed-input/no-op MSBuild baselines for caching, output layout and graph tuning; not task diagnosis or non-MSBuild builds.
build-perf-diagnosticsDiagnose MSBuild target/task/analyzer bottlenecks from binlogs after baselining; not baseline setup, incremental correctness or parallelism tuning.
check-bin-obj-clashDetects MSBuild projects with conflicting OutputPath or IntermediateOutputPath. USE FOR: builds failing with 'Cannot create a file when that file already exists', 'The process cannot access the file because it is being used by another process', intermittent build failures that succeed on retry, or missing/overwritten outputs in multi-project or multi-targeting builds where bin/obj (or project.assets.json) collide. Common causes: shared OutputPath, missing AppendTargetFrameworkToOutputPath, extra global properties (e.g. PublishReadyToRun), or SetTargetFramework on a ProjectReference to a single-targeting project. DO NOT USE FOR: file access errors unrelated to MSBuild (OS-level locking), single-project single-TFM builds, non-MSBuild build systems.
code-testing>-
code-testing-agent>-