Misleading ResolveProjectReferences Time
SkillDev toolsThis is a guide for reading MSBuild performance summaries, focused on the ResolveProjectReferences target. When that target shows up as the most expensive part of a build, your AI can explain what the reported time actually includes, such as waiting on dependent project builds, and direct attention to the real bottleneck. The result is build optimization effort spent in the right place instead of on a misleading number.
Available today. Use it from your connected AI after setup.
No other account needed.
After adding it, share an MSBuild performance summary where ResolveProjectReferences appears as the most expensive target. Your AI will explain what the timing means and point to where the actual slowdown is.
Then ask your AI: use the Misleading ResolveProjectReferences Time skill
What your AI can do with it
- Interpret ResolveProjectReferences timings from MSBuild performance summaries
- Explain that the reported time includes waiting for dependent project builds
- Recognize when ResolveProjectReferences is the most expensive target in a build
- Identify the real build bottleneck behind seemingly slow reference resolution
- Advise on what to optimize instead of chasing the ResolveProjectReferences number
What this skill tells your AI
The instructions your AI receives, as published by dotnet/skills in plugins/dotnet-msbuild/skills/resolve-project-references/SKILL.md and read by ahel’s review.
Prevent misguided optimization of ResolveProjectReferences by explaining that its reported time is wall-clock wait time, not CPU work.
When to Use
ResolveProjectReferencesappears as the most expensive target in the Target Performance Summary- A developer is trying to optimize
ResolveProjectReferencesdirectly - Build performance analysis shows a single target consuming 50-80% of total build time
When Not to Use
- General build performance optimization (use
build-perf-diagnosticsinstead) - The bottleneck is clearly a different target (e.g.,
Csc,ResolveAssemblyReference) - The user has not yet captured a binlog or performance summary
Inputs
| Input | Required | Description |
|---|---|---|
| Build log or binlog | Yes | A diagnostic build log or binlog containing the Target Performance Summary |
Workflow
Step 1: Confirm the misleading symptom
Verify that ResolveProjectReferences appears as the top target in the Target Performance Summary. This is the misleading metric.
Step 2: Explain why it is misleading
The reported time includes waiting for dependent projects to build while the MSBuild node is yielded (see dotnet/msbuild#3135). During this wait, the node may be doing useful work on other projects. The target itself does very little work.
Step 3: Redirect to task self-time
Use the Task Performance Summary to identify the real bottleneck.
Primary: binlog MCP (preferred)
Use the binlog MCP server expensive_tasks tool to get task self-time rankings directly from the binlog.
Fallback: text-log replay (when MCP is unavailable)
dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"
grep "Task Performance Summary" -A 50 full.log
Focus on self-time of actual tasks:
- Csc: see
build-perf-diagnosticsskill (Section 2: Roslyn Analyzers) - ResolveAssemblyReference: see
build-perf-diagnosticsskill (Section 1: RAR) - Copy: see
build-perf-diagnosticsskill (Section 4: File I/O) - Serialization bottlenecks: see
build-parallelismskill
Validation
- Task Performance Summary was used instead of Target Performance Summary
-
ResolveProjectReferenceswas not set as the optimization target - A concrete task (e.g.,
Csc,Copy,ResolveAssemblyReference) was identified as the true bottleneck
Signals
- GitHub stars
- 5k
- Forks
- 414
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
resolve-project-references- Source
- github.com/dotnet/skills