Summary

Microsoft.Testing.Extensions.MSBuild still depends on the internal TestRequestExecutionTimeInfo message from Microsoft.Testing.Platform, so the extension cannot drop IVT yet.

Evidence

• src/Platform/Microsoft.Testing.Platform/Messages/TestRequestExecutionTimeInfo.cs:6-12
  • internal readonly struct TestRequestExecutionTimeInfo(TimingInfo timingInfo) : IData
• src/Platform/Microsoft.Testing.Extensions.MSBuild/MSBuildConsumer.cs:33-37
  • public Type[] DataTypesConsumed { get; } = [ typeof(TestNodeUpdateMessage), typeof(TestRequestExecutionTimeInfo), ];
• src/Platform/Microsoft.Testing.Extensions.MSBuild/MSBuildConsumer.cs:172-179
  • private async Task HandleSummaryAsync(TestRequestExecutionTimeInfo timeInfo, CancellationToken cancellationToken)
  • var runSummaryInfoRequest = new RunSummaryInfoRequest(..., duration);
• src/Platform/Microsoft.Testing.Platform/Requests/TestHostTestFrameworkInvoker.cs:33-34,82-83
  • the platform publishes that same internal message type: DataTypesProduced => [typeof(TestRequestExecutionTimeInfo)]
  • await messageBus.PublishAsync(this, new TestRequestExecutionTimeInfo(...))

Why this is a real issue

Issue #7739 already calls out TestRequestExecutionTimeInfo as a concrete blocker for the MSBuild extension. The current code still consumes that internal type directly, so moving the extension toward a third-party-compatible boundary is blocked even after other IVT cleanup lands.

Suggested resolution

Promote the timing payload to a public/shared contract (or replace it with a public capability/message dedicated to run-summary timing) and switch MSBuildConsumer to that contract. Once that exists, add a regression test ensuring the MSBuild summary still receives duration data without relying on internals.

Related issues

• IVT story for MTP and extensions #7739