-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 forNoBuild
but ALSO for_IsPacking
, which is passed by thedotnet 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