Use platform Run/Install targets instead of custom build for dotnet test

[mattleibow]

Problem

Currently dotnet test via DeviceRunners.Testing.Targets does a custom Build + CLI-driven install/launch. This means:

• Android: We must set EmbedAssembliesIntoApk=true and bake env vars into the APK at build time, because our CLI does adb install which skips Fast Deployment
• iOS: We locate the .app bundle ourselves and launch via the CLI
• macOS: Same — manual .app bundle discovery and direct process launch
• Windows: Manual .exe / AppxManifest.xml detection

Each platform already has SDK-provided targets that handle deployment correctly:

Platform	SDK Target	What it does
Android	_Run / Install	Handles Fast Deployment, adb install, activity launch via RunActivity task
macOS Catalyst	Run (via _PrepareRun)	Handles .app bundle launch
iOS	(needs investigation)	Simulator install/launch
Windows	(needs investigation)	App launch with proper packaging awareness

Proposed Approach

Instead of VSTest → Build → CLI install/launch, use:

VSTest → Build → [Platform Install/Run] → CLI listen

1. Build the app normally (no special EmbedAssembliesIntoApk, no baked env vars)
2. Use dotnet run-style platform targets to deploy and launch the app
3. Pass configuration via CLI args (not env vars) on all platforms — the app already supports --device-runners-* args via AddCliConfiguration()
4. CLI only listens on TCP for results — no install/launch responsibility

Android specifics

The Android SDK _Run target already:

• Handles Fast Deployment (pushes assemblies separately in debug)
• Resolves the activity name from the manifest
• Uses RunActivity MSBuild task to launch

We could extend it to pass intent extras for config (see #123) or use am start --es args. The _Run target uses adb directly, so we could add extra args.

Benefits

• No special build modes: dotnet test produces the same APK/app as dotnet build
• Fast Deployment works: Debug Android builds stay fast
• No env var baking: Android config injected at launch time like all other platforms
• Simpler targets: Just wire into existing SDK targets instead of reimplementing install/launch
• CLI becomes a pure test listener: Single responsibility — just listen on TCP and write TRX

Considerations

• Need to investigate how to pass extra args to each platform's Run target
• Android RunActivity may not support intent extras — may need a custom task
• iOS simulator launch may not have a public MSBuild target
• Windows Run target availability needs investigation
• Need to ensure the CLI can still be started BEFORE the app launches (TCP listener must be ready)

Related

• Android: use intent extras instead of build-time env var injection #123 — Android intent extras for launch-time config injection
• Current implementation in DeviceRunners.Testing.Targets.targets