Issue Description
A csproj with a TargetFrameworks property should only be packed in the build of the project that has no TargetFramework global property defined. Traversal projects honor this, unless -graph is specified at the command line. Then all target frameworks try to pack. When this happens concurrently, the build often fails with a timing break.
Steps to Reproduce
It's simple, really. Take a simple csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net9.0;net8.0</TargetFrameworks>
</PropertyGroup>
</Project>
A traversal that points to it:
<Project Sdk="Microsoft.Build.Traversal">
<ItemGroup>
<ProjectReference Include="SomePackage\SomePackage.csproj" />
</ItemGroup>
</Project>
And a global.json:
{
"sdk": {
"version": "9.0.300",
"rollForward": "patch",
"allowPrerelease": false
},
"msbuild-sdks": {
"Microsoft.Build.Traversal": "4.1.82"
}
}
Or use Repro.zip
Then run dotnet pack -graph -bl. You'll likely see the break. And if you don't, you can try again (after removing build artifacts), or just inspect the .binlog to see that too many GenerateNuspec targets ran.
Then try again with just dotnet pack (again, in a clean state) and it will work properly.
Expected Behavior
I expect dotnet build -graph to run the Pack target only on SomePackage.csproj top-level, no TargetFramework properties specified.
Actual Behavior
Timing break due to overbuild of the Pack target.
SomePackage net9.0 failed with 1 error(s) (0.2s) → SomePackage\bin\Release\net9.0\SomePackage.dll
C:\Program Files\dotnet\sdk\9.0.300\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(221,5): error : The process cannot access the file 'C:\temp\msbuildbugrepro\SomePackage\obj\Release\SomePackage.1.0.0.nuspec' because it is being used by another process.
SomePackage net8.0 succeeded (0.4s) → SomePackage\bin\Release\net8.0\SomePackage.dll
Analysis
No response
Versions & Configurations
No response
Issue Description
A csproj with a
TargetFrameworksproperty should only be packed in the build of the project that has noTargetFrameworkglobal property defined. Traversal projects honor this, unless-graphis specified at the command line. Then all target frameworks try to pack. When this happens concurrently, the build often fails with a timing break.Steps to Reproduce
It's simple, really. Take a simple csproj:
A traversal that points to it:
And a global.json:
{ "sdk": { "version": "9.0.300", "rollForward": "patch", "allowPrerelease": false }, "msbuild-sdks": { "Microsoft.Build.Traversal": "4.1.82" } }Or use Repro.zip
Then run
dotnet pack -graph -bl. You'll likely see the break. And if you don't, you can try again (after removing build artifacts), or just inspect the .binlog to see that too manyGenerateNuspectargets ran.Then try again with just
dotnet pack(again, in a clean state) and it will work properly.Expected Behavior
I expect
dotnet build -graphto run the Pack target only on SomePackage.csproj top-level, no TargetFramework properties specified.Actual Behavior
Timing break due to overbuild of the
Packtarget.Analysis
No response
Versions & Configurations
No response