Guide for diagnosing and improving MSBuild project evaluation performance. USE FOR: builds slow before any compilation starts, high evaluation time in binlog analysis, expensive glob patterns walking large directories (node_modules, .git, bin/obj), deep import chains (>20 levels), preprocessed output >10K lines indicating heavy evaluation, property functions with file I/O ($([System.IO.File]::ReadAllText(...))), multiple evaluations per project. Covers the 5 MSBuild evaluation phases, glob optim
SkillScore77Maintained
Automatic
◆Coding pack
Last verified 8/10/2026
What it changes
Passed 16 of 21 test cases with the skill, and 8 of 21 without it.
Without skill36%
With skill77%
Checks it passed that the model alone missed
Recommend querying the binlog MCP server for evaluation analysis
State that overusing TreatAsLocalProperty adds evaluation overhead
Recommend using graph build (/graph) to reduce redundant evaluations
and 8 more in the full report
9 fixed8 passed either way5 still failing0 broke
Pass-rate lift
+41 pp
Tokens
+15%
Agent turns
0%
Response time
-51%
Model gemini-3.6-flashMeasured 8/10/2026v117 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Which tool within the `Microsoft.AITools.BinlogMcp` server inspects the final evaluated property key-value pairs for a specific project and TargetFramework combination?
What was checked, without and with the skill
Checked
Without skill
With skill
Name the evaluation_properties tool for inspecting evaluated properties
Missed
Passed
case-17 · gemini-3.6-flash · 8/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md123 linessingle file
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.
Initial properties: environment variables, global properties, reserved properties
Imports and property evaluation: process <Import>, evaluate <PropertyGroup> top-to-bottom