mcpbeat

Resolve Project References

microsoft/resolve-project-references

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.

This is a copy. The original lives at dotnet/resolve-project-references.

743 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
1
copies elsewhere
how many repositories repackaged it
1034
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/microsoft/testfx --skill resolve-project-references

The instruction itself

11 sections, as written by the author

Misleading ResolveProjectReferences Time

Prevent misguided optimization of ResolveProjectReferences by explaining that its reported time is wall-clock wait time, not CPU work.

When to Use

  • ResolveProjectReferences appears as the most expensive target in the Target Performance Summary
  • A developer is trying to optimize ResolveProjectReferences directly
  • 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-diagnostics instead)
  • 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-diagnostics skill (Section 2: Roslyn Analyzers)
  • ResolveAssemblyReference: see build-perf-diagnostics skill (Section 1: RAR)
  • Copy: see build-perf-diagnostics skill (Section 4: File I/O)
  • Serialization bottlenecks: see build-parallelism skill

Validation

  • [ ] Task Performance Summary was used instead of Target Performance Summary
  • [ ] ResolveProjectReferences was not set as the optimization target
  • [ ] A concrete task (e.g., Csc, Copy, ResolveAssemblyReference) was identified as the true bottleneck

Repackaged in 1 other repositories

same content, different owner
dotnet/skills open on GitHub →

How to use it

Copy the folder

Take microsoft/resolve-project-references from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.