How do I install the Resolve Project References skill?

Run npx skillmds add majiayu000/resolve-project-references in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Resolve Project References safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Resolve Project References?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Resolve Project References free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Resolve Project References?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Resolve Project References by majiayu000

Name: Resolve Project References
Rating: 4.2 (5 reviews)
Author: majiayu000

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.

majiayu000 55fd0f1 2 files · 3.0 KB Updated Sep 9, 2026 567 repo stars

File contents

Misleading ResolveProjectReferences Time

The Problem

When reviewing the Target Performance Summary from a diagnostic build log, ResolveProjectReferences often appears as the single most expensive target — sometimes consuming 50-80% of total build time. This is misleading.

Why It's Misleading

The reported time for ResolveProjectReferences 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 — it just triggers the build of referenced projects and waits for them to complete. The "time" attributed to it is wall-clock wait time, not CPU work.

Correct Diagnosis

Use Task Performance Summary instead of Target Performance Summary for an accurate picture of where time is actually spent
Focus on self-time of actual tasks: Csc (compilation), ResolveAssemblyReference (RAR), Copy, etc.
Do not optimize ResolveProjectReferences directly — optimize the targets/tasks it's waiting on

How to Get Task Performance Summary

dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"
grep "Task Performance Summary" -A 50 full.log

What to Optimize Instead

Look at the tasks consuming the most cumulative time:

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

---name: resolve-project-referencesdescription: 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.--- ## Misleading ResolveProjectReferences Time ### The Problem When reviewing the **Target Performance Summary** from a diagnostic build log, `ResolveProjectReferences` often appears as the single most expensive target — sometimes consuming 50-80% of total build time. This is **misleading**. ### Why It's Misleading The reported time for `ResolveProjectReferences` 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 — it just triggers the build of referenced projects and waits for them to complete. The "time" attributed to it is wall-clock wait time, not CPU work. ### Correct Diagnosis 1. **Use Task Performance Summary instead of Target Performance Summary** for an accurate picture of where time is actually spent 2. **Focus on self-time** of actual tasks: `Csc` (compilation), `ResolveAssemblyReference` (RAR), `Copy`, etc. 3. **Do not optimize ResolveProjectReferences directly** — optimize the targets/tasks it's waiting on ### How to Get Task Performance Summary ```bash dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary" grep "Task Performance Summary" -A 50 full.log ``` ### What to Optimize Instead Look at the tasks consuming the most cumulative time: - **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

Frequently asked questions