Summary

Converts the dotnet-format integration test pipeline legs (YAML + PowerShell) into MSTest integration tests that run on Helix, eliminating duplicate SDK builds in PR and CI validation. It also narrows the repo coverage to the highest-ROI set (SDK, MSBuild, and ProjectSystem), dropping Roslyn, EfCore, and AspNetCore to reduce compute.

Compute Savings

Measured from build 1519902 (main, 2026-07-21):

Each old leg builds its own full SDK copy before running format. The new approach eliminates this by running as Helix work items on the existing Linux x64 build leg.

What changed

• New test project: test/dotnet-format.IntegrationTests/ using MSTest.Sdk with one test class per repo (SDK, MSBuild, ProjectSystem). Inherits from the MSTest SdkTest base class for standard test infrastructure (logging, binlog arguments).
• Base class pattern: FormatIntegrationTestBase handles clone, Arcade restore, global.json manipulation, solution restore, and format execution with stdout validation. Adding or removing a repo requires only adding or deleting a ~15-line class.
• Dynamic Helix sharding: PartitionByClass=true metadata causes AssemblyScheduler to discover test classes at scheduling time and create one Helix work item per class automatically.
• Conditional test filtering: Uses the ConditionalTests.props DotnetFormat scope with trigger paths. Tests run in PR validation only when relevant files change; they always run in CI.
• Platform targeting: Tests run only on Linux x64 (enforced at the UnitTests.proj scheduling level, not in test code).
• Removed old infrastructure: Deleted eng/dotnet-format/ (YAML template, PowerShell verifier, CMD wrapper, RSP file) and removed pipeline references from .vsts-ci.yml / .vsts-pr.yml.

Design

Each repo is a separate test class inheriting from FormatIntegrationTestBase:

[TestClass]
public class SdkFormatTests : FormatIntegrationTestBase
{
    protected override string RepoUrl => "https://github.com/dotnet/sdk";
    protected override string Sha => "e6bc966cc3d1348265b0831c6daca23267169d8f";
    protected override string TargetSolution => "sdk.slnx";
    protected override string RepoName => "sdk";
}

This one-class-per-repo pattern enables:

1. Helix sharding - each class becomes its own work item (parallel execution)
2. Zero maintenance - adding or removing a repo only requires adding or deleting a class file; sharding adapts automatically

Test lifecycle (mirrors the old format-verifier.ps1)

1. Clone - shallow single-commit fetch of the target SHA
2. Arcade restore - runs eng/Build.ps1 -restore (or eng/build.sh --restore) while global.json is intact to install Arcade SDK tooling
3. Strip global.json sdk section - preserves msbuild-sdks for NuGet SDK resolver but forces the SDK under test to be used
4. Solution restore - restores with the parent SDK's dotnet (NuGet auto-discovers nuget.config via directory walking)
5. Format workspace - dotnet format <solution> --no-restore --verify-no-changes --verbosity detailed
6. Format folder - dotnet format whitespace <path> --folder --verify-no-changes --verbosity detailed
7. Stdout validation - verifies "Formatted X of Y files" appears with Y > 0 (catches silent no-op exits)

Repos dropped

• AspNetCore, EfCore and Roslyn: These repos are resource intensive and have limited ROI. It is recommended that if there are real coverage lost, a follow up issue logged to defined more targeted tests that are less resource intense.

Open questions

Self-format validation removed (validate.rsp)

The old pipeline ran dotnet format --verify-no-changes against src/Dotnet.Format/dotnet-format.slnf to ensure the format source code itself stayed properly formatted. This PR removes that check because maintaining a dedicated pipeline leg or job solely for one project's formatting is disproportionate to the value it provides.

Options going forward:

1. Add a format check to an existing build leg - run dotnet format --verify-no-changes once (e.g., on the Linux x64 leg) as a build step.
2. Drop it entirely - the repo doesn't enforce .editorconfig formatting consistently across all source today, so special-casing one project provides limited value. If format enforcement is desired, it should be applied repo-wide rather than to a single project.