aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging,…
Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills,
Claude Code
$ npx -y skills add managedcode/dotnet-skills --skill binlog-generation --agent claude-code
Codex
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a codex -y
Cursor
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a cursor -y
Gemini CLI
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a gemini-cli -y
GitHub Copilot
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a github-copilot -y
OpenCode
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a opencode -y
Windsurf
$ npx skills add managedcode/dotnet-skills --skill binlog-generation -a windsurf -y
name: binlog-generation
description: "Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead), binlog MCP startup failures (use troubleshoot-binlog-mcp)."
license: MIT**Pass the `/bl` switch when running any MSBuild-based command.** This is a non-negotiable requirement for all .NET builds.
You MUST add the `/bl:{}` flag to:
> **Note:** The `{}` placeholder requires MSBuild 17.8+ / .NET 8 SDK or later.
The `{}` placeholder in the binlog filename is replaced by MSBuild with a unique identifier, guaranteeing no two builds ever overwrite each other — without needing to track or check existing files.
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}**PowerShell requires quoting the complete switch:**
# Keep the literal {} placeholder in one argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'1. **Unique names prevent overwrites** - You can always go back and analyze previous builds 2. **Failure analysis** - When a build fails, the binlog is already there for immediate analysis 3. **Comparison** - You can compare builds before and after changes 4. **No re-running builds** - You never need to re-run a failed build just to generate a binlog
# ✅ CORRECT - {} generates a unique name automatically (bash/cmd)
dotnet build /bl:{}
dotnet test /bl:{}
# ✅ CORRECT - quote the complete PowerShell argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'
# ❌ WRONG - Missing /bl flag entirely
dotnet build
dotnet test
# ❌ WRONG - No filename (overwrites the same msbuild.binlog every time)
dotnet build /bl
dotnet build /blAdd `/bl:{}` to **every** MSBuild invocation separately — never reuse a name and never rely on bare `/bl`:
command still gets its own `/bl:{}` so the logs never overwrite each other.
dotnet build -c Debug /bl:{} # unique file
dotnet build -c Release /bl:{} # another unique fileAfter the build, confirm a `.binlog` was actually produced before moving on to analysis — a build that fails *before* MSBuild starts (e.g. a bad argument) writes no binlog:
ls -1 *.binlog # bash dir /b *.binlog # Windows cmd
Get-ChildItem *.binlog # PowerShell
Note the resulting path so `binlog-failure-analysis` or `build-perf-diagnostics` can consume it.
If the binlog filename needs to be known upfront (e.g., for CI artifact upload), or if `{}` is not available in the installed MSBuild version, pick a name that won't collide with existing files:
1. Check for existing `*.binlog` files in the directory 2. Choose a name not already taken (e.g., by incrementing a counter from the highest existing number)
# Example: directory contains 3.binlog — use 4.binlog dotnet build /bl:4.binlog
When cleaning the repository with `git clean`, **always exclude binlog files** to preserve your build history:
# ✅ CORRECT - Exclude binlog files from cleaning git clean -fdx -e "*.binlog" # ❌ WRONG - This deletes binlog files (they're usually in .gitignore) git clean -fdx
This is especially important when iterating on build fixes - you need the binlogs to analyze what changed between builds.
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.