Agent skill
binlog-generation
Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. Only activate in MSBuild/.NET build context. 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 needs -bl:{{}}. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead). INVOKES: shell commands (dotnet build /bl:{}).
Install this agent skill to your Project
npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/external-sources/upstreams/dotnet-skills/dotnet-msbuild/skills/binlog-generation
SKILL.md
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 builddotnet testdotnet packdotnet publishdotnet restoremsbuildormsbuild.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.
# Every invocation produces a distinct file automatically
dotnet build /bl:{}
dotnet test /bl:{}
dotnet build --configuration Release /bl:{}
PowerShell requires escaping the braces:
# PowerShell: escape { } as {{ }}
dotnet build -bl:{{}}
dotnet test -bl:{{}}
Why This Matters
- Unique names prevent overwrites - You can always go back and analyze previous builds
- Failure analysis - When a build fails, the binlog is already there for immediate analysis
- Comparison - You can compare builds before and after changes
- No re-running builds - You never need to re-run a failed build just to generate a binlog
Examples
# ✅ CORRECT - {} generates a unique name automatically (bash/cmd)
dotnet build /bl:{}
dotnet test /bl:{}
# ✅ CORRECT - PowerShell escaping
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
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:
- Check for existing
*.binlogfiles in the directory - 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
Cleaning the Repository
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.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
dotnet-project-setup
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.
csharp-scripts
Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.
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 existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.
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 private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.
dotnet-legacy-aspnet
Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.
dotnet-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.
Didn't find tool you were looking for?