Interpret MSBuild performance summaries when ResolveProjectReferences appears unusually expensive. Separate time spent waiting for dependent projects from actual task work, then use task self-time rankings to identify a concrete optimization target.
Guide for interpreting ResolveProjectReferences time in MSBuild performance summaries. Activate when ResolveProjectReferences appears as the most expensive target and developers are trying to optimize it directly. Explains that the reported time includes wait time for dependent project builds and is misleading. Guides users to focus on task self-time instead. Do not activate for general build performance -- use build-perf-diagnostics instead.
Review the instructions the agent will receive before you install.
Prevent misguided optimization of ResolveProjectReferences by explaining that its reported time is wall-clock wait time, not CPU work.
ResolveProjectReferences appears as the most expensive target in the Target Performance SummaryResolveProjectReferences directlybuild-perf-diagnostics instead)Csc, ResolveAssemblyReference)| Input | Required | Description |
|---|---|---|
| Build log or binlog | Yes | A diagnostic build log or binlog containing the Target Performance Summary |
Verify that ResolveProjectReferences appears as the top target in the Target Performance Summary. This is the misleading metric.
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.
Use the Task Performance Summary to identify the real bottleneck.
Use the binlog MCP server expensive_tasks tool to get task self-time rankings directly from the binlog.
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:
build-perf-diagnostics skill (Section 2: Roslyn Analyzers)build-perf-diagnostics skill (Section 1: RAR)build-perf-diagnostics skill (Section 4: File I/O)build-parallelism skillResolveProjectReferences was not set as the optimization targetCsc, Copy, ResolveAssemblyReference) was identified as the true bottleneckNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Route GitHub Agentic Workflows requests to the appropriate task guide. It selects prompts for design, creation, updates, debugging, or upgrades, with additional guidance for specialized tasks and repository-specific instructions when available.
Review C#/.NET code for about 50 inefficient API usage patterns across asynchronous work, memory, strings, collections, and I/O. Get exact occurrence counts, prioritized findings, and concrete fixes, with attention to frequently executed code.
Turn .NET runtime addresses in Android crash reports into function names, source files, and line numbers. The skill extracts build identifiers, downloads matching debug symbols, and uses llvm-symbolizer to produce a readable backtrace.
Investigate .NET app crashes on Apple platforms by converting runtime addresses in .ips logs into function names, source files, and line numbers. It locates matching debug symbols and supports retrieving logs from connected iOS devices.
Review existing tests to see whether their assertions, the checks that verify expected behavior, are meaningful and varied. Get metrics, examples of weak checks, and specific recommendations for improving verification.
Create or review Blazor components, reusable parts of a web interface. Covers passing data and events between parent and child components, content templates, asynchronous work, display states, and resource cleanup when components are removed.