
Eval Performance
- 18 installs
- 466 repo stars
- Updated July 25, 2026
- managedcode/dotnet-skills
Helps with ai & agent building tasks.
About
eval-performance is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.
- eval-performance
- AI & Agent Building
- AI-coding skill
Eval Performance by the numbers
- 18 all-time installs (skills.sh)
- +1 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #10,710 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 3, 2026 (Skillselion catalog sync)
npx skills add https://github.com/managedcode/dotnet-skills --skill eval-performanceAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 18 |
|---|---|
| repo stars | ★ 466 |
| Last updated | July 25, 2026 |
| Repository | managedcode/dotnet-skills ↗ |
What it does
Helps with ai & agent building tasks.
Files
MSBuild Evaluation Phases
For a comprehensive overview of MSBuild's evaluation and execution model, see 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
- Globs like
**/*.cswalk 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 - Fix: use
<DefaultItemExcludes>to exclude large directories - Fix: be specific with glob paths:
src/**/*.csinstead of**/*.cs - Fix: use
<EnableDefaultItems>false</EnableDefaultItems>only as last resort (lose SDK defaults) - 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:
/ppoutput → search for<!-- Importingcomments to see import tree - Fix: 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
Property Function Cost
- Property functions execute during evaluation
- Most are cheap (string operations)
- Expensive:
$([System.IO.File]::ReadAllText(...))during evaluation — reads file on every evaluation - Expensive: network calls, heavy computation
- Rule: property functions should be fast and side-effect-free
Optimization Checklist
- [ ] Check preprocessed output size:
dotnet msbuild -pp:full.xml - [ ] Verify evaluation count: should be 1 per project per TFM
- [ ] Exclude large directories from globs
- [ ] Avoid file I/O in property functions during evaluation
- [ ] Minimize import depth
- [ ] Use graph build to reduce redundant evaluations
- [ ] Check for unnecessary UsingTask declarations
{
"version": "0.1.0",
"category": "Core",
"compatibility": "Requires a .NET repository with MSBuild project or solution files."
}