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.
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 https://github.com/dotnet/sdk/pull/478 and https://github.com/dotnet/project-system/issues/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