resolve-project-references

$npx mdskill add microsoft/testfx/resolve-project-references

Identify and address misleading ResolveProjectReferences time in MSBuild performance summaries

  • Confirm that ResolveProjectReferences is consuming an excessive amount of build time.
  • Depends on diagnostic build logs containing Target Performance Summary data.
  • Analyzes the reported time to determine if it includes wait times for dependent projects, suggesting focus on task self-time instead.
  • Provides recommendations and guidance to optimize actual CPU work rather than wait times.

SKILL.md

.github/skills/resolve-project-referencesView on GitHub ↗
---
name: resolve-project-references
description: "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."
license: MIT
---

# 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

More from microsoft/testfx

SkillDescription
assertion-qualityAnalyze assertion quality, depth, variety, and false confidence in existing tests. ALWAYS USE when asked about weak, shallow, trivial, always-true, self-referential, assertion-free, presence/truthiness-only, or insufficiently diverse assertions, including MSTest, Jest, pytest, and Go. DO NOT USE for direct fixes: writing-mstest-tests owns supplied MSTest assertions; code-testing owns new cases. Use test-gap-analysis when asked whether tests would catch a production change, and test-anti-patterns for general severity-ranked audits.
behavior-preserving-refactorPreserve observable behavior when splitting files, moving members, consolidating helpers, or simplifying TestFx code. Use for structural refactors and file-diet implementation; inventory baseline semantics and consumers, then run focused equivalence checks.
binlog-failure-analysisDiagnose existing MSBuild .binlog failures with MCP/replay; not log capture or non-MSBuild failures.
binlog-generationCapture and verify unique MSBuild binlogs, quoting '-bl:{}' in PowerShell; not analysis of existing logs.
build-parallelismAnalyze an MSBuild solution, solution filter, or Build.proj that schedules multiple project files. USE FOR: measured idle worker nodes, `-m` that does not scale, a serial ProjectReference critical path, graph builds, or an MSBuild task that builds a Projects list. Requires at least two distinct project files whose scheduling or throughput must be analyzed. DO NOT USE for non-MSBuild build systems.
build-perf-baselineMeasure repeatable cold/changed-input/no-op MSBuild baselines for caching, output layout and graph tuning; not task diagnosis or non-MSBuild builds.
build-perf-diagnosticsDiagnose MSBuild target/task/analyzer bottlenecks from binlogs after baselining; not baseline setup, incremental correctness or parallelism tuning.
check-bin-obj-clashDetects MSBuild projects with conflicting OutputPath or IntermediateOutputPath. USE FOR: builds failing with 'Cannot create a file when that file already exists', 'The process cannot access the file because it is being used by another process', intermittent build failures that succeed on retry, or missing/overwritten outputs in multi-project or multi-targeting builds where bin/obj (or project.assets.json) collide. Common causes: shared OutputPath, missing AppendTargetFrameworkToOutputPath, extra global properties (e.g. PublishReadyToRun), or SetTargetFramework on a ProjectReference to a single-targeting project. DO NOT USE FOR: file access errors unrelated to MSBuild (OS-level locking), single-project single-TFM builds, non-MSBuild build systems.
code-testing>-
code-testing-agent>-