Rename XUnitV3Project to MTPProject in Helix Sdk (breaking)

[Evangelink]

Summary

Breaking change. Renames the existing XUnitV3Project Helix item type to MTPProject and changes the generated work item command to use only Microsoft.Testing.Platform's built-in flags (no forced reporter args).

xUnit v3 with the Microsoft.Testing.Platform (MTP) runner uses the exact same self-hosting dotnet exec ... <assembly>.dll execution model as MSTest 4.x, NUnit-MTP, TUnit, and any other MTP-based framework. The previous XUnitV3Project and the originally-proposed new MTPProject were 95% the same code; only the reporter args differed. This PR collapses that duplication.

<ItemGroup>
  <MTPProject Include=""..\test\MyApp.Tests\MyApp.Tests.csproj"" />
</ItemGroup>

MTPProject covers any MTP-based test project: MSTest 4.x, xUnit v3 with MTP, NUnit with the MTP runner, TUnit, custom MTP.

What this contains

• Renames CreateXUnitV3WorkItems -> CreateMTPWorkItems, tools/xunitv3-runner/ -> tools/mtp-runner/, XUnitV3Runner.{props,targets} -> MTPRunner.{props,targets}.
• Drops the UseMicrosoftTestingPlatformRunner switch and the legacy -xml/-noAutoReporters xunit-v3 code path. MTP is now the only execution mode for this Helix item type; users still on legacy xunit-v3 native or VSTest hand-author a <HelixWorkItem>.
• Generated command is framework-agnostic. The only MTP flag injected is --results-directory . (built into the MTP core, accepted by every MTP framework), so reporter output lands in the work item working directory. Reporter selection (--report-trx, --report-trx-filename ...) and framework-specific flags (xUnit v3's --auto-reporters off) are NOT forced - they are extension/framework-specific and would error on frameworks that have not opted in to that extension.
• Adds MTPAdditionalArguments property / task parameter as the escape hatch for any extra MTP flags users want applied across every emitted work item.
• Updates Microsoft.DotNet.Helix.Sdk.props (UsingTask), the Helix SDK Readme section, Documentation/AzureDevOps/SendingJobsToHelix.md, and tests/UnitTests.proj (arcade's own self-test).

Generated work item command

dotnet exec --roll-forward Major \
    --runtimeconfig MyApp.Tests.runtimeconfig.json \
    --depsfile MyApp.Tests.deps.json \
    MyApp.Tests.dll \
    --results-directory .

With MTP's --auto-reporters on by default and Microsoft.Testing.Extensions.TrxReport referenced (transitive for MSTest.Sdk and for arcade XUnitV3.targets), the TRX reporter activates automatically and writes a default-named *.trx file into the work item directory; arcade's existing TRXFormat Python reporter globs *.trx so the auto-generated filename is fine.

Why a breaking rename instead of additive

The previous draft of this PR (which left XUnitV3Project in place and added a parallel MTPProject) was reviewed offline. Conclusion: the two paths are identical except for the reporter flag, so duplicating the task + targets + props infrastructure is purely accidental complexity. A rename is cheaper to maintain and clearer to users.

Downstream impact

A code search across dotnet/* (and public GitHub) shows dotnet/efcore/eng/helix.proj is the only in-tree consumer of XUnitV3Project (5 occurrences: 1 Include + 4 Remove). efcore already sets UseMicrosoftTestingPlatformRunner=true in test/Directory.Build.props, so they're on the MTP code path today.

Migration for efcore is mechanical:

	Today	After this PR
Item type	<XUnitV3Project>	<MTPProject>
Report format	xUnit XML (--report-xunit-xml-filename testResults.xml)	TRX produced automatically by Microsoft.Testing.Extensions.TrxReport
Reporter package	Microsoft.Testing.Extensions.XunitXmlReport (transitive via arcade XUnitV3.targets)	Microsoft.Testing.Extensions.TrxReport (also transitive via arcade XUnitV3.targets)
--auto-reporters off	injected automatically	opt in via <MTPAdditionalArguments>--auto-reporters off</MTPAdditionalArguments>

Concretely: 5 occurrences of XUnitV3Project in eng/helix.proj get renamed to MTPProject. If they want to preserve the current --auto-reporters off behaviour they add <MTPAdditionalArguments>--auto-reporters off --report-trx --report-trx-filename testResults.trx</MTPAdditionalArguments> (the explicit --report-trx is needed when --auto-reporters is off). Otherwise the TRX auto-reporter picks up automatically. A follow-up PR against efcore tracking this migration will be opened before this PR is merged (see #17001 for the broader rollout-coordination tracking).

Prerequisites for users

Test projects must reference Microsoft.Testing.Extensions.TrxReport:

• MSTest.Sdk projects: included transitively, nothing to do.
• xUnit v3 projects built with Microsoft.DotNet.Arcade.Sdk's XUnitV3 targets: included implicitly, nothing to do.
• NUnit-MTP / TUnit / custom MTP: add <PackageReference Include=""Microsoft.Testing.Extensions.TrxReport"" /> to the test project.

AzureDevOps reporter caveat

The MTP Microsoft.Testing.Extensions.AzureDevOpsReport only activates when --report-azdo is explicitly passed AND TF_BUILD=true. We never pass --report-azdo, so there is no risk of a duplicate AzDO test run on top of the one the Helix SDK already opens. If a user has wired --report-azdo into their test project they should drop it for Helix runs, or pass --auto-reporters off via MTPAdditionalArguments.

Out of scope

• Test sharding via --list-tests + --treenode-filter.
• A Microsoft.Testing.Extensions.HelixReport MTP extension (would live in microsoft/testfx).
• HELIX_DUMP_FOLDER awareness in CrashDump / HangDump MTP extensions (microsoft/testfx).
• The unconditional --roll-forward Major is pre-existing and unchanged from CreateXUnitV3WorkItems; tracking removal/narrowing in Helix Sdk MTP/xUnit work items unconditionally pass --roll-forward Major which can silently mask missing runtimes #17000.

Tracking

• Add first-class MSTest (and generic MTP) support to Microsoft.DotNet.Helix.Sdk microsoft/testfx#8926
• Helix Sdk MTP/xUnit work items unconditionally pass --roll-forward Major which can silently mask missing runtimes #17000 (--roll-forward Major follow-up, pre-existing)
• Track downstream-repo migration for Helix Sdk XUnitV3Project -> MTPProject rename (breaking) #17001 (downstream rollout coordination)

[Copilot]

Pull request overview

This PR extends Microsoft.DotNet.Helix.Sdk with first-class support for Microsoft Testing Platform (MTP) test projects by introducing new item types (MSTestProject, MTPProject) that auto-publish and generate Helix work items, analogous to the existing XUnitV3Project experience.

Changes:

• Add CreateMTPWorkItems MSBuild task to generate Helix work items for published MTP test assemblies.
• Add mtp-runner props/targets to restore/publish MTP projects and emit HelixWorkItem items automatically.
• Document usage, prerequisites, and patterns for MSTest/NUnit/TUnit and other MTP-based test projects in the Helix SDK readme.

Show a summary per file

File	Description
src/Microsoft.DotNet.Helix/Sdk/tools/mtp-runner/MTPRunner.targets	Adds restore/publish pipeline for @(MTPProject) and folds @(MSTestProject) into it before creating work items.
src/Microsoft.DotNet.Helix/Sdk/tools/mtp-runner/MTPRunner.props	Hooks the new MTP runner targets into the Helix SDK’s mono-queue target import chain.
src/Microsoft.DotNet.Helix/Sdk/tools/Microsoft.DotNet.Helix.Sdk.props	Registers the new CreateMTPWorkItems task via UsingTask.
src/Microsoft.DotNet.Helix/Sdk/Readme.md	Documents MSTestProject / MTPProject usage, prerequisites, and guidance around TRX + AzDO reporting.
src/Microsoft.DotNet.Helix/Sdk/CreateMTPWorkItems.cs	Implements the new task to generate HelixWorkItem command/payload/timeout for MTP projects, including dedup logic.

Copilot's findings

• Files reviewed: 5/5 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 9/9 changed files
• Comments generated: 2

[Copilot]

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 0 new

[Youssef1313]

(MTP) runner (which is the default for v3)

I don't think this is correct. The default for xunit.v3 is xunit's runner AFAIK.

[Copilot]

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 4

[Copilot]

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 1