Problem
The evaluation EventSource events currently expose the project file and evaluation ID, but not the configuration being evaluated.
A project can be evaluated multiple times with different global properties. Showing only its path or evaluation ID makes it difficult to understand which configuration produced a particular evaluation duration.
For example, PerfStar should be able to describe a measured evaluation as:
Project.csproj
Configuration=Release
TargetFramework=net10.0
RuntimeIdentifier=win-x64
Proposed change
Expose configuration context alongside the existing evaluation telemetry, either through a backward-compatible event version or a separate, reliably correlated event.
The context should remain associated with the individual evaluation that produced the timing. Keep correlation IDs for distinguishing repeated evaluations; project path and properties alone do not uniquely identify an invocation.
Clarify whether the reported values are supplied global properties or evaluated properties. Values such as TargetFramework are not always supplied as global properties.
Requirements
- Preserve compatibility with existing EventSource consumers.
- Support correlation across processes and repeated evaluations without assuming evaluation IDs are globally unique.
- Define a safe, bounded property payload; do not indiscriminately emit potentially sensitive global-property values.
- Avoid unnecessary work when telemetry is disabled and measure the overhead when enabled.
- Do not require collecting a full binary log to obtain this context.
- Document behavior for partial/failed evaluations and missing configuration information.
Problem
The evaluation EventSource events currently expose the project file and evaluation ID, but not the configuration being evaluated.
A project can be evaluated multiple times with different global properties. Showing only its path or evaluation ID makes it difficult to understand which configuration produced a particular evaluation duration.
For example, PerfStar should be able to describe a measured evaluation as:
Proposed change
Expose configuration context alongside the existing evaluation telemetry, either through a backward-compatible event version or a separate, reliably correlated event.
The context should remain associated with the individual evaluation that produced the timing. Keep correlation IDs for distinguishing repeated evaluations; project path and properties alone do not uniquely identify an invocation.
Clarify whether the reported values are supplied global properties or evaluated properties. Values such as TargetFramework are not always supplied as global properties.
Requirements