Add dotnet test device selection support for MAUI

[jonathanpeppers]

Summary

Adds --device option to dotnet test (MTP path) for .NET MAUI projects, enabling per-target-framework device selection.

Behavior

• Default: dotnet test iterates all target frameworks without prompting (existing behavior unchanged)
• Per-TFM device prompting: For each TFM, if ComputeAvailableDevices target exists, uses RunCommandSelector to handle device selection (auto-select single device, error in non-interactive mode with multiple devices)
• --device: When specified without -f, forces a target framework prompt since devices are platform-specific
• Non-interactive: Errors with a helpful message when prompting would be required but stdin is redirected / CI. Interactive mode is auto-detected (same logic as dotnet run).

Changes

• TestCommandDefinition.MicrosoftTestingPlatform.cs - Added DeviceOption
• Options.cs / MSBuildUtility.cs - Device on BuildOptions
• MicrosoftTestingPlatformTestCommand.cs - HandleDeviceWithTargetFrameworkSelection() for --device + TF selection
• SolutionAndProjectUtility.cs - TrySelectDeviceForProject() called per-TFM before running tests
• dotnet-run-for-maui.md - Updated spec with dotnet test behavior section
• MTPHelpSnapshotTests.VerifyMTPHelpOutput.verified.txt - Updated snapshot for new --device option

Tests

7 integration tests in GivenDotnetTestSelectsDevice covering:

• Non-interactive failure with multiple devices
• Specified device (2 variants)
• Auto-select single device
• TF prompt with --device in non-interactive mode
• Combined -f + --device
• Projects without ComputeAvailableDevices target

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/Cli/dotnet/Commands/Test/MTP/MicrosoftTestingPlatformTestCommand.cs:200

• When buildOptions.IsInteractive is false, RunCommandSelector.TrySelectTargetFramework(...) already writes a detailed error message (including the available TFMs) to stderr before returning false. Throwing a new GracefulException with the same message causes duplicated output. Consider avoiding the extra exception message in non-interactive mode (for example by returning an exit code to the caller, or by throwing an exception marked as already displayed).

                if (!RunCommandSelector.TrySelectTargetFramework(frameworks, buildOptions.IsInteractive, out string? selectedFramework))
                {
                    // Error already written to stderr by TrySelectTargetFramework
                    throw new GracefulException(
                        string.Format(CliCommandStrings.RunCommandExceptionUnableToRunSpecifyFramework, "--framework"));
                }

src/Cli/dotnet/Commands/Test/MTP/SolutionAndProjectUtility.cs:358

• RunCommandSelector.TrySelectDevice(...) prints a full non-interactive error (including the available devices list) before returning false. Throwing another GracefulException with the same top-line message will duplicate output. Consider throwing an exception that doesn’t print a second message (or refactor to propagate a failure/exit code up to the command) so users see a single error block.

        {
            // Device selection failed - error already written to stderr by TrySelectDevice
            throw new GracefulException(
                string.Format(CliCommandStrings.RunCommandExceptionUnableToRunSpecifyDevice, "--device"));
        }

[jonathanpeppers]

Filed #54378 to track this. --list-devices for dotnet test was intentionally deferred to a later phase — this PR only covers --device and --interactive (Phase 1).

[Evangelink]

Reviewed the PR end-to-end. Posting comments only (no change requested). The two threading findings are the most important to address before merge; the rest are listed for awareness and follow-up.

Summary of findings

#	Area	File / Line	Severity
1	Threading	SolutionAndProjectUtility.cs ~L348 — selector.TrySelectDevice(...) inside Parallel.ForEach	Likely blocking
2	Threading	Same site, interactive prompt path	Blocking for interactive multi-project case
3	Correctness / ordering	SolutionAndProjectUtility.cs ~L362 — SetProperty("Device"/"RuntimeIdentifier") after build	Major
4	Defensive coding	MicrosoftTestingPlatformTestCommand.cs ~L217 — -p:Device=... injected unconditionally	Major
5	Documentation accuracy	documentation/specs/dotnet-run-for-maui.md L143/L155/L157 — --list-devices for dotnet test not implemented	Major
6	Test coverage	GivenDotnetTestSelectsDevice.cs — several missing scenarios	Major
7	Performance	SolutionAndProjectUtility.cs ~L342 — per-TFM RunCommandSelector re-evaluates project	Moderate
8	Nits	HandleDeviceWithTargetFrameworkSelection	Minor

Thanks for the well-structured PR (good doc updates and a dedicated test asset). Inline comments below have suggested fixes for each finding.

[Evangelink]

🟡 Defensive coding — --device injected unconditionally, even for projects that don't support devices

HandleDeviceWithTargetFrameworkSelection never checks whether the resolved project actually defines a ComputeAvailableDevices target. So if a user mistakenly types dotnet test --device foo against a normal MSTest / xUnit / NUnit project:

• Multi-TFM: they get a forced target-framework prompt (or an error in non-interactive mode) for a flag that has no meaning for their project, and then -p:Device=foo is appended anyway.
• Single-TFM: -p:Device=foo is silently appended. Harmless today, but it makes the contract unclear and complicates future work that consumes $(Device) for non-MAUI scenarios.

Compare with TrySelectDeviceForProject in SolutionAndProjectUtility.cs (~L320) which correctly probes projectInstance.Targets.ContainsKey(Constants.ComputeAvailableDevices) first — that guard should also exist on the --device path.

Suggested fix

After resolving the project file in HandleDeviceWithTargetFrameworkSelection, do a cheap targets probe before forcing the TF prompt and before appending the property. Roughly:

if (!projectInstance.Targets.ContainsKey(Constants.ComputeAvailableDevices))
{
    throw new GracefulException(
        "--device is only supported for projects that define a ComputeAvailableDevices MSBuild target (e.g. .NET MAUI).");
}

For multi-TFM, ideally the check is done per resolved TFM (since the target may be imported conditionally per platform). A pragmatic shortcut: check on the cross-targeting evaluation first; if absent across the board, error out. Localize the message via a new CliCommandStrings resource (and an English .resx entry for translators to follow up on).

[jonathanpeppers]

The ComputeAvailableDevices target isn't required for the --device switch, this behavior is the same as dotnet run.

Passing the -p:Device global property is just passed along no matter what. I can't think of a platform or scenario that would use $(Device) and not have ComputeAvailableDevices, though.

[Evangelink]

🟢 Performance — per-TFM RunCommandSelector re-evaluates the project

Minor: TrySelectDeviceForProject constructs new RunCommandSelector(projectFilePath, ...) and lets it open + evaluate the project from scratch on every call, while the caller already has a fully evaluated ProjectInstance in hand. For a solution with N projects × M TFMs that's N×M extra evaluations on top of the ones GetProjectProperties already does — non-trivial on large MAUI solutions.

Not a correctness issue, and not a blocker for this PR; consider as follow-up. Options:

• Pass the already-evaluated ProjectInstance (and the shared EvaluationContext) into a new RunCommandSelector constructor overload so it skips its own OpenProjectIfNeeded call.
• Or extract the ComputeAvailableDevices build call into a small free helper that takes a ProjectInstance directly, so dotnet test can avoid RunCommandSelector entirely on this path.

[jonathanpeppers]

Partially addressed in f6298f2 — SelectDevicesBeforeBuild now has an overload that accepts a shared ProjectCollection and EvaluationContext, avoiding redundant evaluations in the solution path. The RunCommandSelector itself still does its own evaluation since it needs to call Build() for ComputeAvailableDevices, but the outer evaluation layer no longer doubles up.