Additional fix for --no-build in pack with transitive references#511
Additional fix for --no-build in pack with transitive references#511
Conversation
Turns out that the .NET SDK lifts transitive project references as direct references (without any additional metadata), and this causes the second-level dependency from being built unexpectedly (see dotnet/sdk#478 and dotnet/project-system#199). Since we don't want to disrupt the IDE (BuildingInsideVisualStudio) and we only want to fix this for the very specific case of running from the CLI `dotnet pack --no-build`, we make the fix very constrained for that scenario. We check for `NoBuild` but ALSO for `_IsPacking`, which is passed by the `dotnet pack` command. This ensures minimal impact in all other scenarios, since we're essentially turning off a built-in behavior in the SDK that has explicit side-effects (by design and desirable) and we should preserve. #Fixes 501
🧪 Details on Microsoft Windows 10.0.20348✅ NuGetizer.AssignPackagePathTests.assigned_files_contains_all_files from dotnet-retest v0.6.1 on .NET 8.0.7 with 💜 |
Turns out that the .NET SDK lifts transitive project references as direct references (without any additional metadata), and this causes the second-level dependency from being built unexpectedly (see dotnet/sdk#478 and dotnet/project-system#199).
Since we don't want to disrupt the IDE (BuildingInsideVisualStudio) and we only want to fix this for the very specific case of running from the CLI
dotnet pack --no-build, we make the fix very constrained for that scenario. We check forNoBuildbut ALSO for_IsPacking, which is passed by thedotnet packcommand.This ensures minimal impact in all other scenarios, since we're essentially turning off a built-in behavior in the SDK that has explicit side-effects (by design and desirable) and we should preserve.
Fixes #501