/eval-performance

name: eval-performance
description: "Diagnose measured MSBuild evaluation cost before targets run. USE FOR: evaluation-only repeats under global-property variants, expensive node_modules/.git/bin/obj globs, import depth >20, /pp >10K lines, file-I/O property functions, five-phase evaluation. DO NOT USE FOR: duplicate executions (find-repeated-work-within-one-build), execution bottlenecks (build-perf-diagnostics), incremental rebuilds (incremental-build), non-MSBuild systems."
license: MIT

Diagnosing MSBuild Evaluation Performance

Evaluation is the work MSBuild does *before* any target runs — reading project files, processing imports, expanding globs. This skill helps you **find and confirm** evaluation bottlenecks. Measure first; recommend a change only when a measurement proves it is warranted.

Confirm the problem before changing anything

Engage only when evaluation is *measurably* the bottleneck. Do NOT act when:

• **The slowness is during compilation or target execution, not evaluation.**

That is not an evaluation problem — use `build-perf-diagnostics` instead.

• **The complaint is "rebuilds too much" / incremental build.** Use

`incremental-build` instead.

• **You have no measurement.** If no binlog or timing summary shows evaluation

is slow, gather one first (see below). Do not guess from reading project files.

• **A pattern below appears but evaluation is already fast.** Broad globs, deep

imports, or `EnableDefaultItems` are only worth flagging when the numbers show they cost real time. A project that evaluates quickly needs no change.

When a pattern is present but unmeasured, **report it as an observation and let the user decide** — do not rewrite working configuration to match a "best practice" without evidence it costs measurable evaluation time. Prefer the smallest, most targeted change; never disable SDK defaults as a first move.

MSBuild Evaluation Phases

For a comprehensive overview of MSBuild's evaluation and execution model, see [Build process overview](https://learn.microsoft.com/en-us/visualstudio/msbuild/build-process-overview).

1. **Initial properties**: environment variables, global properties, reserved properties 2. **Imports and property evaluation**: process `<Import>`, evaluate `<PropertyGroup>` top-to-bottom 3. **Item definition evaluation**: `<ItemDefinitionGroup>` metadata defaults 4. **Item evaluation**: `<ItemGroup>` with `Include`, `Remove`, `Update`, glob expansion 5. **UsingTask evaluation**: register custom tasks

Key insight: evaluation happens BEFORE any targets run. Slow evaluation = slow build start even when nothing needs compiling.

Diagnosing Evaluation Performance

Primary: binlog MCP (preferred)

Use the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the `binlog` MCP namespace) to analyze evaluation performance:

1. Use the evaluations tool to list all evaluations and their durations 2. Use evaluation_global_properties to check for multiple evaluations with differing global properties 3. Use evaluation_properties to inspect evaluated properties for a specific project+TFM 4. Use imports tool to analyze the import chain depth and structure 5. Use properties tool to check for expensive property function evaluations

Fallback: text-log replay and preprocessing (when MCP is unavailable)

Using binlog

1. Replay the binlog: `dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log"` 2. Search for evaluation events: `grep -i 'Evaluation started\|Evaluation finished' full.log` 3. Multiple evaluations for the same project = overbuilding 4. Look for "Project evaluation started/finished" messages and their timestamps

Using /pp (preprocess)

• `dotnet msbuild -pp:full.xml MyProject.csproj`
• Shows the fully expanded project with ALL imports inlined
• Use to understand: what's imported, import depth, total content volume
• Large preprocessed output (>10K lines) = heavy evaluation

Using /clp:PerformanceSummary

• Add to build command for timing breakdown
• Shows evaluation time separately from target/task execution

Expensive Glob Patterns

Only pursue these remedies once a measurement shows item evaluation is slow and the globs are the cause; a custom glob that isn't walking large trees is fine.

• Globs like `**/*.cs` walk the entire directory tree
• Default SDK globs are optimized, but custom globs may not be
• Problem: globbing over `node_modules/`, `.git/`, `bin/`, `obj/` — millions of files
• Remedy: use `<DefaultItemExcludes>` to exclude large directories
• Remedy: be specific with glob paths: `src/**/*.cs` instead of `**/*.cs`
• Remedy: use `<EnableDefaultItems>false</EnableDefaultItems>` only as a last resort (loses SDK defaults) — prefer the two options above first
• Check: grep for Compile items in the diagnostic log → if Compile items include unexpected files, globs are too broad

Import Chain Analysis

• Deep import chains (>20 levels) slow evaluation
• Each import: file I/O + parse + evaluate
• Common causes: NuGet packages adding .props/.targets, framework SDK imports, Directory.Build chains
• Diagnosis: `/pp` output → search for `<!-- Importing` comments to see import tree
• Remedy (only if the chain is measurably costly): reduce transitive package imports where possible, consolidate imports

Multiple Evaluations

• A project evaluated multiple times = wasted work
• Common causes: referenced from multiple other projects with different global properties
• Each unique set of global properties = separate evaluation
• Diagnosis: `grep 'Evaluation started.*ProjectName' full.log` → if count > 1, check for differing global properties
• Fix: normalize global properties, use graph build (`/graph`)

TreatAsLocalProperty

• Prevents property values from flowing to child projects via MSBuild task
• Overuse: declaring many TreatAsLocalProperty entries adds evaluation overhead
• Correct use: only when you genuinely need to override an inherited property