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
ResolveProjectReferencesappears as the most expensive target in the Target Performance Summary- A developer is trying to optimize
ResolveProjectReferencesdirectly - 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-diagnosticsinstead) - 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
Guide the user to use the Task Performance Summary instead:
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-diagnosticsskill (Section 2: Roslyn Analyzers) - ResolveAssemblyReference: see
build-perf-diagnosticsskill (Section 1: RAR) - Copy: see
build-perf-diagnosticsskill (Section 4: File I/O) - Serialization bottlenecks: see
build-parallelismskill
Validation
- Task Performance Summary was used instead of Target Performance Summary
-
ResolveProjectReferenceswas not set as the optimization target - A concrete task (e.g.,
Csc,Copy,ResolveAssemblyReference) was identified as the true bottleneck
More from managedcode/dotnet-skills
dotnet
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
18dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10