# Resolve Project References

> Prevents misguided optimization of MSBuild's ResolveProjectReferences target by explaining that its reported time is wall-clock wait time, not CPU work, and redirects to task self-time analysis.

- Skill: `dotnet/resolve-project-references` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dotnet/resolve-project-references`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dotnet/resolve-project-references/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, Productivity, CI/CD
- Tags: Binlog, Build Performance, Dotnet, Msbuild, Resolvereferences
- License: MIT
- Author: .NET (Microsoft) (https://skillmd.com/u/dotnet), verified publisher
- Updated: 2026-07-06
- Page: https://skillmd.com/skills/dotnet/resolve-project-references

---


# 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)

```bash
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