/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
$ npx -y skills add dotnet/skills --skill resolve-project-references --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/resolve-project-references
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
resolve-project-references.SKILL.mdname: 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)
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
Read more
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)
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
This repository contains the .NET team's curated set of core skills and custom agents for coding agents. For information about the Agent Skills standard, see agentskills.io. 📊 Dashboard - Accuracy and efficiency scoring trends for contained plugins (
Repo: dotnet/skills
Other skills on dotnet-skills.
- /csharp-scripts
Run file-based C# apps with the .NET CLI when the user explicitly wants C#/.NET code without creating a project. Use for C# language/API experiments, one-file C# apps, small multi-file C# apps composed with `#:include`/`#:exclude`, or C# file-based apps linked with `#:ref`. Do
Open skill - /dotnet-pinvoke
Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging
Open skill - /nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to
Open skill - /technology-selection
Guides technology selection and implementation of AI and ML features in .NET 8+ applications using ML.NET, Microsoft.Extensions.AI (MEAI), Microsoft Agent Framework (MAF), GitHub Copilot SDK, ONNX Runtime, and OllamaSharp. Covers the full spectrum from classic ML through modern
Open skill - /configuring-opentelemetry-dotnet
Configure OpenTelemetry distributed tracing, metrics, and logging in ASP.NET Core using the .NET OpenTelemetry SDK. Use when adding observability, setting up OTLP exporters, creating custom metrics/spans, or troubleshooting distributed trace correlation.
Open skill - /convert-blazor-server-to-webapp
Guides conversion of a pre-.NET 8 Blazor Server app into a .NET 8+ Blazor Web App. USE FOR: migrating apps that use AddServerSideBlazor and MapBlazorHub to the AddRazorComponents/MapRazorComponents model, converting _Host.cshtml to an App.razor root component, replacing
Open skill

