Fix TerminalLogger assert failure for metaproj files and cached project eval ID

[OvesN]

Fixes #13095

Context

These metaproj files are never evaluated — they have EvaluationId = -1. The TerminalLogger's Debug.Assert assumes every ProjectStarted has a prior ProjectEvaluationFinished, which fails for metaproj files and crashes the build.

Additionally, a pre-existing bug (#12953) causes real projects to lose their evaluation IDs when their ProjectInstance is cached (released from memory), and when BuildResult packets are sent from worker nodes to the central node without carrying the eval ID.

Changes Made

TerminalLogger metaproj fix:

• TerminalLogger.cs: Assert "EvalProjectInfo should have been captured before ProjectStarted"); will not fail now for metaproj files

Evaluation ID fixes (adapted from PR #12946):

• BuildRequestConfiguration.cs: Added _projectEvaluationId field that persists through caching + IPC serialization in both Translate() and TranslateForFutureUse()
• NodeLoggingContext.cs: Use config.ProjectEvaluationId instead of config.Project.EvaluationId (which is inaccessible when cached)
• BuildResult.cs: Added _evaluationId field with version 2 serialization
• RequestBuilder.cs: Populate result.EvaluationId at success, exception, and abort paths
• BuildManager.cs: Update config.ProjectEvaluationId from worker node results

Testing

Unit tests

• BuildRequestConfiguration_Tests
• BuildResult_Tests

Integration testing:

• Verified by building Roslyn and Aspire with Debug bootstrap MSBuild with and without /mt.

Notes

• The evaluation ID fixes are adapted from PR Fill holes in BuildEventContext construction and evaluation ID propagation #12946.

[Copilot]

Pull request overview

Fixes TerminalLogger crashes and restores correct evaluation ID propagation across caching and cross-node result transfers, improving BuildEventContext consistency in multi-node (/m, /mt) builds.

Changes:

• Make TerminalLogger’s ProjectStarted debug assertion tolerant of non-evaluated .metaproj projects.
• Persist and propagate project evaluation IDs through configuration caching, node logging, worker→central result transfer, and BuildResult serialization.
• Add/adjust unit tests for BuildResult/configuration serialization of evaluation IDs.

Reviewed changes

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

Show a summary per file

File	Description
src/Framework/FileUtilities.cs	Makes .metaproj detection helpers null-tolerant for broader call-site safety.
src/Build/Logging/TerminalLogger/TerminalLogger.cs	Avoids Debug.Assert failure for .metaproj projects that never emit evaluation events.
src/Build/BuildCheck/Infrastructure/BuildCheckBuildEventHandler.cs	Centralizes metaproject detection by using FileUtilities.IsMetaprojectFilename.
src/Build/BackEnd/Shared/BuildResult.cs	Adds versioned _evaluationId field to allow eval ID propagation via result serialization.
src/Build/BackEnd/Shared/BuildRequestConfiguration.cs	Persists evaluation ID independently of cached ProjectInstance accessibility and serializes it.
src/Build/BackEnd/Components/RequestBuilder/RequestBuilder.cs	Populates BuildResult.EvaluationId for success/abort/exception paths.
src/Build/BackEnd/Components/Logging/NodeLoggingContext.cs	Uses persisted ProjectEvaluationId instead of reading from a potentially cached project.
src/Build/BackEnd/BuildManager/BuildManager.cs	Updates configuration evaluation ID from worker node results when available.
src/Build.UnitTests/TerminalLogger_Tests.cs	Whitespace-only adjustments.
src/Build.UnitTests/BackEnd/BuildResult_Tests.cs	Adds test to validate translation preserves EvaluationId.
src/Build.UnitTests/BackEnd/BuildRequestConfiguration_Tests.cs	Adds tests for ProjectEvaluationId preservation (translation/clone/future-use path).

[rainersigwald]

#13489 should improve the test that flaked out on the current run. I'm not rerunning because I'm not convinced this is the right solution to the problem thouh.

[OvesN]

@rainersigwald
Regarding your comment about deprecating older versions: the comment says "backwards compatible with at least 2
previous releases." We are now on version 2 and have two previous versions, 0 and 1. So I guess we do not need to
deprecate anything.

[rainersigwald]

@rainersigwald Regarding your comment about deprecating older versions: the comment says "backwards compatible with at least 2 previous releases." We are now on version 2 and have two previous versions, 0 and 1. So I guess we do not need to deprecate anything.

I interpreted "releases" there as MSBuild releases, not this specific version that changes rarely. But this is not blocking.

[rainersigwald]

Hit rerun after putting up #13546 to hopefully stabilize the test that flaked.