aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging,…
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
Claude Code
$ npx -y skills add managedcode/dotnet-skills --skill resolve-project-references --agent claude-code
Codex
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a codex -y
Cursor
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a cursor -y
Gemini CLI
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a gemini-cli -y
GitHub Copilot
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a github-copilot -y
OpenCode
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a opencode -y
Windsurf
$ npx skills add managedcode/dotnet-skills --skill resolve-project-references -a windsurf -y
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
Prevent misguided optimization of `ResolveProjectReferences` by explaining that its reported time is wall-clock wait time, not CPU work.
| Input | Required | Description | |-------|----------|-------------| | Build log or binlog | Yes | A diagnostic build log or binlog containing the Target Performance Summary |
Verify that `ResolveProjectReferences` appears as the top target in the **Target** Performance Summary. This is the misleading metric.
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.
Use the **Task** Performance Summary to identify the real bottleneck.
Use the **binlog MCP server** expensive_tasks tool to get task self-time rankings directly from the binlog.
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:
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging,…
Build, upgrade, and operate Aspire 13.5.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults,…
Build and debug Avalonia 11/12 .NET applications with XAML, compiled bindings, MVVM, custom controls, desktop lifetimes, and…
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable…
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design,…
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.