Loading
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 b
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add dotnet/skills --skill check-bin-obj-clash -a cursor -y
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.
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.
This skill helps identify when multiple MSBuild project evaluations share the same OutputPath or IntermediateOutputPath. This is a common source of build failures including:
Cannot create a file when that file already exists - this strongly indicates multiple projects share the same IntermediateOutputPath where project.assets.json is writtenClashes can occur between:
TargetFrameworks=net8.0;net9.0) where the path doesn't include the target frameworkNote: 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.
Invoke this skill immediately when you see:
Cannot create a file when that file already exists during NuGet restoreThe process cannot access the file because it is being used by another processUse the binlog-generation skill to generate a binary log with the correct naming convention.
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:
.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.Use the MCP overview and projects tools to understand the build and list all projects that participated.
Use the MCP evaluations and evaluation_global_properties tools to find all evaluations per project. Look for:
TargetFramework, Configuration, RuntimeIdentifier, SolutionFileName, PublishReadyToRun, etc.)Use the MCP properties tool to query OutputPath, IntermediateOutputPath, BaseOutputPath, and BaseIntermediateOutputPath for each project evaluation.
Use the MCP double_writes tool if available — it directly detects files written by multiple project instances.
Compare the OutputPath and IntermediateOutputPath values across all evaluations:
BuildProjectReferences=false instances (P2P queries)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:
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.)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).grep -iE 'TargetFramework|Configuration|Platform|RuntimeIdentifier|SolutionFileName|PublishReadyToRun' full.log. See the Global Properties to Check table for which affect the path and which just fork a redundant instance.grep 'Target "CopyFilesToOutputDirectory"' full.log plus grep 'SkipUnchangedFiles' full.log show a second instance writing (or skipping a masked write) to the same path; a long vs ~0 ms CoreCompile distinguishes the real build from a redundant instance.Then identify clashes: normalize paths to absolute, group evaluations by OutputPath and by IntermediateOutputPath, and exclude BuildProjectReferences=false (P2P queries) — plus, for OutputPath only, MSBuildRestoreSessionId restore evaluations. Any group with more than one remaining evaluation is a clash.
Problem: Project uses TargetFrameworks but OutputPath doesn't vary by framework.
<OutputPath>bin\$(Configuration)\</OutputPath>
Fix: Include TargetFramework in the path:
<OutputPath>bin\$(Configuration)\$(TargetFramework)\</OutputPath>
Or rely on SDK defaults which handle this automatically:
<AppendTargetFrameworkToOutputPath>true</AppendTargetFrameworkToOutputPath>
<AppendTargetFrameworkToIntermediateOutputPath>true</AppendTargetFrameworkToIntermediateOutputPath>
Problem: Multiple projects explicitly set the same BaseOutputPath or BaseIntermediateOutputPath.
<BaseOutputPath>..\SharedOutput\</BaseOutputPath>
<BaseIntermediateOutputPath>..\SharedObj\</BaseIntermediateOutputPath>
<BaseOutputPath>..\SharedOutput\</BaseOutputPath>
<BaseIntermediateOutputPath>..\SharedObj\</BaseIntermediateOutputPath>
IMPORTANT: Even with AppendTargetFrameworkToOutputPath=true, this will still clash! .NET writes certain files directly to the IntermediateOutputPath without the TargetFramework suffix, including:
project.assets.json (NuGet restore output)This causes errors like Cannot create a file when that file already exists during parallel restore.
Fix: Each project MUST have a unique BaseIntermediateOutputPath. Do not share intermediate output directories across projects:
<BaseIntermediateOutputPath>..\obj\ProjectA\</BaseIntermediateOutputPath>
<BaseIntermediateOutputPath>..\obj\ProjectB\</BaseIntermediateOutputPath>
Or simply use the SDK defaults which place obj inside each project's directory.
Problem: Building for multiple RIDs without RID in path.
Fix: Ensure RuntimeIdentifier is in the path:
<AppendRuntimeIdentifierToOutputPath>true</AppendRuntimeIdentifierToOutputPath>
Problem: A single build invokes multiple solutions (e.g., via MSBuild task or command line) that include the same project. Each solution build evaluates and builds the project independently, with different Solution* global properties that don't affect the output path.
How to detect: Compare SolutionFileName and CurrentSolutionConfigurationContents across evaluations for the same project. Different values indicate multi-solution builds. For example:
| Property | Eval from Solution A | Eval from Solution B |
|---|---|---|
SolutionFileName | BuildAnalyzers.sln | Main.slnx |
CurrentSolutionConfigurationContents | 1 project entry | ~49 project entries |
OutputPath | bin\Release\netstandard2.0\ | bin\Release\netstandard2.0\ ← clash |
Example: A repo build script builds BuildAnalyzers.sln then Main.slnx, and both solutions include SharedAnalyzers.csproj. Both builds write to bin\Release\netstandard2.0\. The first build compiles; the second skips compilation but still runs CopyFilesToOutputDirectory.
Fix: Options include:
Configuration values that result in different output pathsProblem: A project is built multiple times within the same solution due to extra global properties (e.g., PublishReadyToRun=false) that create distinct MSBuild project instances. These properties don't affect output paths but prevent MSBuild from caching results across instances, causing redundant target execution.
How to detect: Compare global properties across evaluations for the same project within the same solution (same SolutionFileName). Look for properties that differ but don't contribute to path differentiation:
| Property | Eval A (from Razor.slnx) | Eval B (from Razor.slnx) |
|---|---|---|
PublishReadyToRun | (not set) | false |
OutputPath | bin\Release\netstandard2.0\ | bin\Release\netstandard2.0\ ← clash |
This is particularly wasteful for projects where the extra property has no effect (e.g., PublishReadyToRun on a netstandard2.0 class library that doesn't use ReadyToRun compilation).
Fix: Options include:
RemoveGlobalProperties metadata - On ProjectReference items, use RemoveGlobalProperties="PublishReadyToRun" to strip the property before building the referenced project<MSBuild> Build/Publish with extra global properties (self or cross-project)Problem: A target uses the <MSBuild> task to build or publish a project with an extra global property, most commonly a "publish-on-build" target. The offending call can be in the target project itself or in another project that consumes it (e.g. a test or layout project publishing a tool):
<Target Name="PublishOnBuild" AfterTargets="Build">
<MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Publish" Properties="_IsPublishing=true" />
</Target>
<MSBuild Projects="..\tool\tool.csproj" Targets="Publish" Properties="_IsPublishing=true" />
Either way this forks a distinct instance of the target project (path + {_IsPublishing=true}) that shares the same OutputPath/IntermediateOutputPath as the instance the solution/graph already builds. Both write the same files — for NativeAOT this includes the *.sourcelink intermediate, which produces SourceLinkWriter / "file in use" failures under parallel builds.
How to detect: Follow the Primary workflow above — the evaluations and evaluation_global_properties tools surface two evaluations of the target project that share the same OutputPath/IntermediateOutputPath but differ only by a path-neutral publish flag such as _IsPublishing, and the double_writes tool flags the resulting shared-file writes directly. To tell case (a) from (b), see which project the extra {_IsPublishing=true} evaluation runs under in the build tree (from the overview/projects tools): the target project itself for (a), or a consumer project that invoked the <MSBuild> task for (b).
Fix: Depends on where the call lives:
RemoveGlobalProperties (the project injects it on itself). Set the flag as a static (non-global) property and run the target in the same instance via DependsOnTargets/CallTarget, with a guard against a target cycle when publish is the entry point:<PropertyGroup>
<_PublishWasInvokedDirectly Condition="'$(_IsPublishing)' == 'true'">true</_PublishWasInvokedDirectly>
<_IsPublishing>true</_IsPublishing>
</PropertyGroup>
<Target Name="PublishOnBuild"
AfterTargets="Build"
DependsOnTargets="Publish"
Condition="'$(_PublishWasInvokedDirectly)' != 'true'" />
<ItemGroup>
<ProjectReference Include="..\tool\tool.csproj" ReferenceOutputAssembly="false" />
</ItemGroup>
See the msbuild-antipatterns skill (AP-22) for the authoring-time smell and rationale.
SetTargetFramework re-injecting a single-targeting project's own TFM on a ProjectReferenceProblem: A ProjectReference sets SetTargetFramework="TargetFramework=<tfm>" metadata pointing at a single-targeting project (one that uses singular <TargetFramework>, not <TargetFrameworks>), where the injected <tfm> equals the TFM the project already targets. SetTargetFramework injects TargetFramework as a global property on the referenced project's build.
<ProjectReference Include="..\Tool\Tool.csproj" SetTargetFramework="TargetFramework=net8.0" />
Injecting the TFM the project already targets is path-neutral — the project already resolves to bin\<config>\net8.0\ and obj\<config>\net8.0\ on its own. So it doesn't change the output path; it only forks a distinct instance (project, {TargetFramework=net8.0}). The solution/graph builds the very same project as (project, {}). Both share the same OutputPath/IntermediateOutputPath, so the project is built twice to the same location — a bin/obj clash under parallel builds.
How to detect: Follow the Primary workflow above. The evaluations and evaluation_global_properties tools surface two evaluations of the referenced project that share the same OutputPath/IntermediateOutputPath and differ only by a TargetFramework global property, while the project itself is single-targeting (its own TargetFramework already equals the injected value). The double_writes tool flags the resulting shared-file writes directly.
Note: The P2P protocol itself does not inject TargetFramework for a non-multi-targeting reference — the clash comes specifically from the explicit SetTargetFramework metadata overriding that safe default.
Fix: Remove the redundant SetTargetFramework when it just restates the project's own single TFM:
<ProjectReference Include="..\Tool\Tool.csproj" />
When SetTargetFramework is legitimate (not a clash):
Multi-targeting reference — the referenced project uses <TargetFrameworks> and you need one specific TFM. Each TFM has a distinct output path, so no clash.
Overriding to a different TFM — you may use SetTargetFramework on a single-targeting project to build it under a TFM other than the one it declares. Because the injected TFM then changes the output path (obj\<config>\<different-tfm>\), the instance no longer collides with (project, {}). Only the same-TFM case is path-neutral and clashing.
Framework-incompatible reference — whenever the referencing and referenced projects target incompatible frameworks (e.g. a .NETFramework project referencing a .NETCoreApp project, or vice-versa) — regardless of single- or multi-targeting on either side — set SkipGetTargetFrameworkProperties="true" (the P2P GetTargetFrameworkProperties negotiation would otherwise fail) and ReferenceOutputAssembly="false" (an assembly built for an incompatible framework can't be consumed as a reference — you only want to trigger/sequence the build):
<ProjectReference Include="..\Tool\Tool.csproj"
SkipGetTargetFrameworkProperties="true"
ReferenceOutputAssembly="false" />
With SkipGetTargetFrameworkProperties="true", the negotiation no longer stops the referencing project's own TargetFramework global property (present when it builds for a specific TFM, e.g. it is multi-targeting) from flowing into the referenced project. For a single-targeting referenced project that would force it to build under the wrong TFM / output path. Prevent it by either setting SetTargetFramework="TargetFramework=<tfm>" (pin the TFM) or UndefineProperties="TargetFramework" (strip the inherited global property so the project builds as it declares) — use one, not both:
<ProjectReference Include="..\Tool\Tool.csproj"
SkipGetTargetFrameworkProperties="true"
UndefineProperties="TargetFramework"
ReferenceOutputAssembly="false" />
See the msbuild-antipatterns skill (AP-23) for the authoring-time smell and rationale.
$(TargetFramework) — clashes often occur when projects override these defaults; normalize relative paths to absolute before comparing.IntermediateOutputPath clashes cannot be fixed with AppendTargetFrameworkToOutputPath — files like project.assets.json are written directly to the intermediate path. For multi-targeting clashes within the same project, AppendTargetFrameworkToOutputPath=true is the correct fix.Cannot create a file when that file already exists (NuGet restore), The process cannot access the file because it is being used by another process, or intermittent failures that succeed on retry.When multiple evaluations share an output path, compare these global properties to understand why:
| Property | Affects OutputPath? | Notes |
|---|---|---|
TargetFramework | Yes | Different TFMs should have different paths. Exception: re-injecting a single-targeting project's own TFM (e.g. via SetTargetFramework with the same value) is path-neutral — it forks a redundant instance sharing the output path (see "SetTargetFramework re-injecting...") |
RuntimeIdentifier | Yes | Different RIDs should have different paths |
Configuration | Yes | Debug vs Release |
Platform | Yes | AnyCPU vs x64 etc. |
SolutionFileName | No | Identifies which solution built the project — different values indicate multi-solution clash |
SolutionName | No | Solution name without extension |
SolutionPath | No | Full path to the solution file |
SolutionDir | No | Directory containing the solution file |
CurrentSolutionConfigurationContents | No | XML with project entries — count of entries reveals which solution |
BuildProjectReferences | No | false = P2P query, not a real build - ignore these |
MSBuildRestoreSessionId | No | Present = restore phase evaluation |
PublishReadyToRun | No | Publish setting, doesn't change build output path but creates distinct project instances |
_IsPublishing | No | Publish flag; an <MSBuild> Build/Publish call with this set (in this project or another that consumes it) forks a publish instance sharing the build output path (see "Explicit <MSBuild> Build/Publish with extra global properties") |
After making changes to fix path clashes, clean and rebuild to verify. See the binlog-generation skill's "Cleaning the Repository" section on how to clean the repository while preserving binlog files.