/check-bin-obj-clash

name: check-bin-obj-clash
description: "Detects MSBuild projects with conflicting OutputPath or IntermediateOutputPath. USE FOR: builds failing with 'Cannot create a file when that file already exists', 'The process cannot access the file because it is being used by another process', intermittent build failures that succeed on retry, or missing/overwritten outputs in multi-project or multi-targeting builds where bin/obj (or project.assets.json) collide. Common causes: shared OutputPath, missing AppendTargetFrameworkToOutputPath, extra global properties (e.g. PublishReadyToRun), or SetTargetFramework on a ProjectReference to a single-targeting project. DO NOT USE FOR: file access errors unrelated to MSBuild (OS-level locking), single-project single-TFM builds, non-MSBuild build systems."
license: MIT

Detecting OutputPath and IntermediateOutputPath Clashes

Overview

This skill helps identify when multiple MSBuild project evaluations share the same `OutputPath` or `IntermediateOutputPath`. This is a common source of build failures including:

• File access conflicts during parallel builds
• Missing or overwritten output files
• Intermittent build failures
• "File in use" errors
• **NuGet restore errors like `Cannot create a file when that file already exists`** - this strongly indicates multiple projects share the same `IntermediateOutputPath` where `project.assets.json` is written

Clashes can occur between:

• **Different projects** sharing the same output directory
• **Multi-targeting builds** (e.g., `TargetFrameworks=net8.0;net9.0`) where the path doesn't include the target framework
• **Multiple solution builds** where the same project is built from different solutions in a single build

**Note:** Project instances with `BuildProjectReferences=false` should be **ignored** when analyzing clashes - these are P2P reference resolution builds that only query metadata (via `GetTargetPath`) and do not actually write to output directories.

When to Use This Skill

**Invoke this skill immediately when you see:**

• `Cannot create a file when that file already exists` during NuGet restore
• `The process cannot access the file because it is being used by another process`
• Intermittent build failures that succeed on retry
• Missing output files or unexpected overwriting

Step 1: Generate a Binary Log

Use the `binlog-generation` skill to generate a binary log with the correct naming convention.

Primary workflow — binlog MCP

The MCP server exposes structured tools for inspecting a `.binlog` without parsing text logs. Call them directly instead of replaying the binlog to a text file. Call `tools/list` for the MCP first if you are unsure which tools are available.

**Important constraints:**

• The `.binlog` file is a **binary format** — do NOT try to `cat`, `head`, `strings`, or read it directly. Use only the MCP tools to query it.
• **Synthesize findings as you go.** Do not spend all available time investigating — once you have enough evidence, present your conclusions.

Step 2: Get an overview and list projects

Use the MCP overview and projects tools to understand the build and list all projects that participated.

Step 3: Check evaluations and global properties

Use the MCP `evaluations` and `evaluation_global_properties` tools to find all evaluations per project. Look for:

• Multiple evaluations for the same project (indicates multi-targeting or multiple build configurations)
• Differing global properties between evaluations (`TargetFramework`, `Configuration`, `RuntimeIdentifier`, `SolutionFileName`, `PublishReadyToRun`, etc.)

Step 4: Get output paths for each evaluation

Use the MCP properties tool to query `OutputPath`, `IntermediateOutputPath`, `BaseOutputPath`, and `BaseIntermediateOutputPath` for each project evaluation.

Step 5: Check for double writes

Use the MCP double_writes tool if available — it directly detects files written by multiple project instances.

Step 6: Identify clashes

Compare the `OutputPath` and `IntermediateOutputPath` values across all evaluations: 1. **Normalize paths** - Convert to absolute paths and normalize separators 2. **Group by path** - Find evaluations that share the same OutputPath or IntermediateOutputPath 3. **Filter out non-build evaluations** - Exclude `BuildProjectReferences=false` instances (P2P queries) 4. **Report clashes** - Any group with more than one evaluation indicates a clash

Fallback workflow — text-log replay (when MCP is unavailable)

Use this only when the MCP server cannot be started.

Replay the binlog to a diagnostic text log, then grep for the same signals the MCP tools surface:

dotnet msbuild build.binlog -noconlog -fl -flp:v=diag;logfile=full.log

Then extract the clash signals:

• **Projects & evaluations** — list evaluation starts and count them per project: `grep 'Evaluation started' full.log | grep -oiE '"[^"]+\.[a-z]+proj"' | sort | uniq -c`. Matching the full **quoted path** keeps same-named projects in different directories distinct (and tolerates spaces in paths); a path with a count ≥ 2 was evaluated more than once (multi-targeting or extra global properties). (`grep -c` alone only totals evaluations across the whole log, so it can't reveal per-project duplication.)
• **Output paths** — `grep -iE 'OutputPath[[:space:]]*=|IntermediateOutputPath[[:space:]]*=|BaseOutputPath[[:space:]]*=|BaseIntermediateOutputPath[[:space:]]*=' full.log | sort -u`, or query a project directly: `dotnet msbuild MyProject.csproj -getProperty:OutputPath` (and `IntermediateOutputPath`, `BaseIntermediateOutputPath`).
• **Distinguishing global properties** — `grep -iE 'TargetFramework|Configuration|Platform|RuntimeIdentifier|SolutionFileName|PublishReadyToRun' full.log`. See the [Global Properties to Check](#global-properties-to-check-when-comparing-evaluations) table for which affect the path and which just fork a redundant instance.
• **Corroborating evidence (optional)** — `grep 'Tar