AGENT SKILL

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 caching. Do not activate for IDE-based builds (Visual Studio already uses a long-lived process).

使用场景后端与接口
License 许可
MIT
所属仓库
microsoft/testfx
最近更新
2026-11-12
Stars
★ 1.1k
Forks
315

01 前言 Front Matter

name
msbuild-server
license
MIT
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).

03 SKILL.md 正文

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

04 同仓库更多 Skills

microsoft
microsoft/testfx

dotnet-breaking-changes

Use before changing .NET/C# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped/Unshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: "without breaking existing callers"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016/RS0017 or ApiCompat errors; "is this PR breaking?". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework/SDK/NuGet upgrades (use dotnet-upgrade).

★ 1.1k
microsoft
microsoft/testfx

testfx-test-value-evidence

Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.

测试与质量
★ 1.1k
microsoft
microsoft/testfx

testfx-parallel-safety-preflight

Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.

★ 1.1k
microsoft
microsoft/testfx

testfx-localization-validation

Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX/XLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.

★ 1.1k
microsoft
microsoft/testfx

testfx-acceptance-validation

Validate TestFx shipping paths and capable CI execution using packed consumers, package/cache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package/MSBuild/launcher/protocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.

测试与质量
★ 1.1k
microsoft
microsoft/testfx

session-delivery-hygiene

Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package/output mismatches, or handing off implementation.

★ 1.1k