Prototype cross-process evaluation cache

[OvesN]

Fixes #

Context

This is an intentionally unsafe prototype for measuring the happy-path benefit of reusing project evaluations across consecutive MSBuild invocations and worker processes.

The prototype assumes project files, imports, SDK inputs, environment inputs, and global properties are unchanged. It is not intended for production use.

Changes Made

• Add an opt-in process-local evaluated ProjectInstance cache enabled by MSBUILDPROTOTYPEEVALUATIONCACHE=1.
• Add an optional serialized cross-process cache configured by MSBUILDPROTOTYPEEVALUATIONCACHEDIRECTORY.
• Key the happy-path cache by project identity and the stable configuration dimensions needed by the OrchardCore restore/build outer and inner configurations.
• Deep-copy cached in-memory instances so target execution receives mutable state.
• Record cache-hit materialization duration through a prototype metrics instrument.
• Leave build-result caching unchanged, so targets continue to execute.

Testing

• Full repository build: passed with 0 warnings and 0 errors.
• Focused BuildRequestConfiguration_Tests: 42 passed on net10.0.
• Broader Build engine test run: 10,619 passed, 118 skipped, and 17 failures in unrelated graph, platform, task-host, preprocessor, and terminal-logger tests.
• Execution probe: two cache-enabled builds produced two execution records, confirming execution was not skipped.

OrchardCore Release warm no-op build, 232 solution projects, 32 logical processors:

Metric	Cache disabled	Shared-cache hit	Zero-overhead estimate
Evaluation count	916	2	2
Evaluation CPU time	131.34 s	0.138 s	0.138 s
Median wall-clock time	65.075 s	56.076 s	48.375 s
Cache materialization wall-time union	—	7.701 s	0 s
Wall-clock saving	—	8.999 s	16.700 s
Wall-clock improvement	—	13.8%	25.7%

Notes

• There is no invalidation.
• The selected global-property key is deliberately incomplete and only represents the measured happy path.
• The serialized cache includes filesystem and cloning overhead and is only a way to share evaluated state between fresh CLI, server, and worker processes.
• A production cache would need complete dependency tracking, versioning, eviction, concurrency design, and a safer representation than serialized mutable engine state.