Default BuildProjectReferences to false when NoBuild is true

[baronfel]

Summary

• Default BuildProjectReferences to false for SDK projects when NoBuild=true.
• Prevent project-to-project reference resolution from invoking Build and triggering NETSDK1085 during no-build operations.
• Preserve explicit BuildProjectReferences=true behavior.
• Add regression coverage that exercises ResolveReferences on a prebuilt project-reference graph and verifies the explicit opt-in failure path.

Testing

• Microsoft.NET.Build.Tests.GivenThatWeWantToReferenceAProject.It_does_not_build_project_references_when_no_build_is_requested

Fixes #55176

[Copilot]

Pull request overview

This PR updates the .NET SDK’s default MSBuild behavior so that when NoBuild=true is used, SDK-style projects will default BuildProjectReferences to false. This prevents project-to-project reference resolution from invoking Build on referenced projects (and thereby avoids triggering NETSDK1085) while preserving the opt-in behavior when BuildProjectReferences=true is explicitly set.

Changes:

• Default BuildProjectReferences=false for SDK projects when NoBuild=true.
• Add a regression test covering ResolveReferences under NoBuild=true, plus the explicit opt-in failure path (BuildProjectReferences=true) that should still produce NETSDK1085.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
test/Microsoft.NET.Build.Tests/GivenThatWeWantToReferenceAProject.cs	Adds regression coverage ensuring ResolveReferences succeeds under NoBuild=true and still fails with NETSDK1085 when opting back into building project references.
src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props	Adds a defaulting rule: when NoBuild=true and BuildProjectReferences is unset, default it to false for SDK projects.

[baronfel]

cc @ViktorHofer - if this gets in then we may not need NuGet/NuGet.Client#7541 because the evaluations should magically line up.

[ViktorHofer]

if this gets in then we may not need NuGet/NuGet.Client#7541 because the evaluations should magically line up.

My understanding is that we still need NuGet/NuGet.Client#7541 as the global properties continue to differ, even after this change and therefore extra evaluations gets triggered.

[baronfel]

Oh duh, of course you're right.