Skip to main content
skill CX Codex

binlog-generation — Claude Code skill: what it does, how to install

The skill makes your agent add /bl:{} to every MSBuild command, so each build leaves a .binlog with a full trace you can inspect after a failure or a slowdown.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add dotnet/skills --skill binlog-generation -a claude-code
Open on GitHub

What binlog-generation does

It appends the /bl:{} switch to anything that runs MSBuild: dotnet build, test, pack, publish, restore, and bare msbuild. A .binlog stays behind with the whole execution trace. Your agent does it on every invocation, no prompting required.

The {} placeholder gets swapped for a unique identifier, so back-to-back builds never overwrite one file. That needs MSBuild 17.8+ or .NET 8 SDK and newer — on older versions the placeholder stays literal and you pick a name yourself; the skill suggests scanning for existing *.binlog files and taking a free number. PowerShell needs the whole switch quoted as '-bl:{}', otherwise the braces get mangled before MSBuild sees them.

After the build, the agent confirms the file exists. A run that dies before MSBuild starts, say on a bad argument, writes no binlog at all. The skill also covers git clean -fdx: without -e "*.binlog" it wipes your build history, and with it the chance to compare before and after a fix. The logs feed binlog-failure-analysis and build-perf-diagnostics, which have nothing to read without them.

What it helps with

  • capture a binlog from a failed build without re-running it
  • keep separate logs for Debug and Release builds
  • hand a build trace to binlog-failure-analysis
  • survive git clean -fdx with build logs intact

Example prompts for the agent

  • Build the solution with /bl:{} so I get a binlog
  • Run dotnet test '-bl:{}' in PowerShell and tell me where the file landed
  • Rebuild in Release with /bl:{} and compare it to the previous binlog

How to install binlog-generation

1Skills CLI (Vercel)

npx skills add dotnet/skills --skill binlog-generation -a claude-code

2Manually: put the files in place

~/.claude/skills/binlog-generation/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/binlog-generation/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about binlog-generation

How do I install binlog-generation in Claude Code?

Run npx skills add dotnet/skills --skill binlog-generation -a claude-code. The skill lands in ~/.claude/skills/binlog-generation/SKILL.md.

What does binlog-generation do?

It adds /bl:{} to dotnet build, test, pack, publish, restore and msbuild calls so a .binlog with the full execution trace is left after the run. That file is what build error and build timing investigations read later.

When does the {} placeholder work?

Only on MSBuild 17.8+ or .NET 8 SDK and newer. On older versions you set the filename yourself — check for existing *.binlog files and pick one that is free.

Source text

SKILL.md · MIT
---
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
---

# Generate Binary Logs

**Pass the `/bl` switch when running any MSBuild-based command.** This is a non-negotiable requirement for all .NET builds.

## Commands That Require /bl

You MUST add the `/bl:{}` flag to:
- `dotnet build`
- `dotnet test`
- `dotnet pack`
- `dotnet publish`
- `dotnet restore`
- `msbuild` or `msbuild.exe`
- Any other command that invokes MSBuild

## Preferred: Use `{}` for Automatic Unique Names

> **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.

```bash
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}
```

**PowerShell requires quoting the complete switch:**

```powershell
# Keep the literal {} placeholder in one argument
dotnet build '-bl:{}'
dotnet test '-bl:{}'
```

## Why This Matters

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

## Examples

```bash
# ✅ 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 /bl
```

## One build = one binlog

Add `/bl:{}` to **every** MSBuild invocation separately — never reuse a name and
never rely on bare `/bl`:

- Building several configurations, projects, or retrying a failed build? Each
  command still gets its own `/bl:{}` so the logs never overwrite each other.

```bash
dotnet build -c Debug   /bl:{}   # unique file
dotnet build -c Release /bl:{}   # another unique file
```

## Verify the binlog exists

After 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:

```bash
ls -1 *.binlog       # bash
dir /b *.binlog      # Windows cmd
```

```powershell
Get-ChildItem *.binlog   # PowerShell
```

Note the resulting path so `binlog-failure-analysis` or `build-perf-diagnostics`
can consume it.

## When a Specific Filename Is Required

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)

```bash
# Example: directory contains 3.binlog — use 4.binlog
dotnet build /bl:4.binlog
```

## Cleaning the Repository

When cleaning the repository with `git clean`, **always exclude binlog files** to preserve your build history:

```bash
# ✅ 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.

© dotnet · MIT · dotnet/skills

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set101

dotnet-trace-collect Guides developers in selecting diagnostic tools and capturing traces for production .NET performance issues across Windows, Linux, and containers. CX Codex +1 3,800installs msbuild-modernization A skill that rewrites legacy .NET project files to SDK-style: trims the XML, moves packages to PackageReference, hands assembly attributes to the SDK. CX Codex +1 3,700installs directory-build-organization A skill that decides what belongs in Directory.Build.props, .targets and .rsp, so several projects stop repeating the same MSBuild policy. CX Codex +1 3,700installs coverage-analysis Interpret .NET line, branch, and condition coverage, find gaps, and diagnose plateaus. Use it to examine Cobertura reports or assess project-wide refactoring risk. CX Codex +1 3,600installs dotnet-pinvoke Calls C and C++ native libraries from .NET via DllImport and LibraryImport. Helps map signatures accurately, configure string marshalling, and prevent memory corruption. CX Codex +1 3,500installs build-perf-diagnostics This skill reads binlog timelines and Performance Summaries to show where a .NET build loses time. Handy when the slowdown has no obvious cause. CX Codex +1 3,500installs test-gap-analysis Maps which caller-visible production outcomes could change without any existing test failing. Useful before you trust a suite to guard a change. CX Codex +1 3,500installs crap-score Calculates Change Risk Anti-Patterns (CRAP) scores for .NET methods, classes, and files. It highlights complex code that lacks adequate test coverage. CX Codex +1 3,500installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor