From dotnet-msbuild
Detects MSBuild/.NET projects with shared OutputPath/IntermediateOutputPath causing file conflicts, intermittent failures, and missing outputs in multi-project/multi-TFM builds.
npx claudepluginhub dotnet/skills --plugin dotnet-msbuildThis skill uses the workspace's default tool permissions.
This skill helps identify when multiple MSBuild project evaluations share the same `OutputPath` or `IntermediateOutputPath`. This is a common source of build failures including:
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
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.
dotnet msbuild build.binlog -noconlog -fl -flp:v=diag;logfile=full.log
grep -i 'done building project\|Building project' full.log | grep -oP '"[^"]+\.csproj"' | sort -u
This lists all project files that participated in the build.
Multiple evaluations for the same project indicate multi-targeting or multiple build configurations:
# Count how many times each project was evaluated
grep -c 'Evaluation started' full.log
grep 'Evaluation started.*\.csproj' full.log
For each project, query the build properties to understand the build configuration:
# Search the diagnostic log for evaluated property values
grep -i 'TargetFramework\|Configuration\|Platform\|RuntimeIdentifier' full.log | head -40
Look for properties like TargetFramework, Configuration, Platform, and RuntimeIdentifier that should differentiate output paths.
Also check solution-related properties to identify multi-solution builds:
SolutionFileName, SolutionName, SolutionPath, SolutionDir, SolutionExt — differ when a project is built from multiple solutionsCurrentSolutionConfigurationContents — the number of project entries reveals which solution an evaluation belongs to (e.g., 1 project vs ~49 projects)Look for extra global properties that don't affect output paths but create distinct MSBuild project instances:
PublishReadyToRun — a publish setting that doesn't change OutputPath or IntermediateOutputPath, but MSBuild treats it as a distinct project instance, preventing result caching and causing redundant target execution (e.g., CopyFilesToOutputDirectory running again)When analyzing clashes, filter evaluations based on the type of clash you're investigating:
For OutputPath clashes: Exclude restore-phase evaluations (where MSBuildRestoreSessionId global property is set). These don't write to output directories.
For IntermediateOutputPath clashes: Include restore-phase evaluations, as NuGet restore writes project.assets.json to the intermediate output path.
Always exclude BuildProjectReferences=false: These are P2P metadata queries, not actual builds that write files.
Query each project's output path properties:
# From the diagnostic log - search for OutputPath assignments
grep -i 'OutputPath\s*=\|IntermediateOutputPath\s*=\|BaseOutputPath\s*=\|BaseIntermediateOutputPath\s*=' full.log | head -40
# Or query a specific project directly
dotnet msbuild MyProject.csproj -getProperty:OutputPath
dotnet msbuild MyProject.csproj -getProperty:IntermediateOutputPath
dotnet msbuild MyProject.csproj -getProperty:BaseOutputPath
dotnet msbuild MyProject.csproj -getProperty:BaseIntermediateOutputPath
Compare the OutputPath and IntermediateOutputPath values across all evaluations:
As additional evidence for OutputPath clashes, check if multiple project builds execute the CopyFilesToOutputDirectory target to the same path. Note that not all clashes manifest here - compilation outputs and other targets may also conflict.
# Search for CopyFilesToOutputDirectory target execution per project
grep 'Target "CopyFilesToOutputDirectory"' full.log
# Look for Copy task messages showing file destinations
grep 'Copying file from\|SkipUnchangedFiles' full.log | head -30
Look for evidence of clashes in the messages:
Copying file from "..." to "..." - Active file writesDid not copy from file "..." to file "..." because the "SkipUnchangedFiles" parameter was set to "true" - Indicates a second build attempted to write to the same locationThe SkipUnchangedFiles skip message often masks clashes - the build succeeds but is vulnerable to race conditions in parallel builds.
To understand which project instance did the actual compilation vs redundant work, check CoreCompile:
grep 'Target "CoreCompile"' full.log
Compare the durations:
CoreCompile duration (e.g., seconds) is the primary build that did the actual compilationCoreCompile was skipped (duration ~0-10ms) are redundant builds — they didn't recompile but may still run other targets like CopyFilesToOutputDirectory that write to the same output directoryThis helps distinguish the "real" build from redundant instances created by extra global properties or multi-solution builds.
When analyzing multi-solution builds, note that the diagnostic log interleaves output from all projects. To determine which solution a project instance belongs to, search for SolutionFileName property assignments in the diagnostic log:
grep -i "SolutionFileName\|CurrentSolutionConfigurationContents" full.log | head -20
For each evaluation, collect:
For each unique OutputPath:
- If multiple evaluations share it → CLASH
For each unique IntermediateOutputPath:
- If multiple evaluations share it → CLASH
Problem: Project uses TargetFrameworks but OutputPath doesn't vary by framework.
<!-- BAD: Same path for all frameworks -->
<OutputPath>bin\$(Configuration)\</OutputPath>
Fix: Include TargetFramework in the path:
<!-- GOOD: Path varies by framework -->
<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.
<!-- Project A - Directory.Build.props -->
<BaseOutputPath>..\SharedOutput\</BaseOutputPath>
<BaseIntermediateOutputPath>..\SharedObj\</BaseIntermediateOutputPath>
<!-- Project B - Directory.Build.props -->
<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:
<!-- Project A -->
<BaseIntermediateOutputPath>..\obj\ProjectA\</BaseIntermediateOutputPath>
<!-- Project B -->
<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# 1. Replay the binlog
dotnet msbuild build.binlog -noconlog -fl -flp:v=diag;logfile=full.log
# 2. List projects
grep 'done building project' full.log | grep -oP '"[^"]+\.csproj"' | sort -u
# 3. Check OutputPath for each evaluation
grep -i 'OutputPath\s*=' full.log | sort -u
# e.g. OutputPath = bin\Debug\net8.0\
# OutputPath = bin\Debug\net9.0\
# 4. Check IntermediateOutputPath
grep -i 'IntermediateOutputPath\s*=' full.log | sort -u
# e.g. IntermediateOutputPath = obj\Debug\net8.0\
# IntermediateOutputPath = obj\Debug\net9.0\
# 5. Compare paths → No clash (paths differ by TargetFramework)
grep -i 'OutputPath\s*=' full.log | sort -u to quickly find all OutputPath property assignmentsBaseOutputPath and BaseIntermediateOutputPath as they form the root of output paths$(TargetFramework) - clashes often occur when projects override these defaultsAppendTargetFrameworkToOutputPath - files like project.assets.json are written directly to the intermediate pathAppendTargetFrameworkToOutputPath=true is the correct fixCannot create a file when that file already exists (NuGet restore)The process cannot access the file because it is being used by another processWhen 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 |
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 |
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.