Fix MAUI iOS simulator launch in VS Code

[adamint]

Description

Fixes #17853

This makes Aspire's MAUI resources debuggable from the VS Code extension instead of falling back to a plain dotnet run terminal launch. The useful user-facing path is: start the AppHost under the Aspire debugger, start a MAUI platform resource from the Aspire tree/dashboard flow, and get the MAUI extension's normal debugger behavior with the right target selected.

The PR now covers Mac Catalyst, Windows, iOS simulator/device metadata, and Android emulator/device metadata. Android also avoids the bad stopped-emulator path where we passed -p:AdbTarget=-s <avd-name> too early and the MAUI build failed with XA0010: Selected device is not running; for stopped emulators we select the MAUI active target and let the MAUI extension launch/resolve the emulator.

User-facing usage

Existing MAUI AppHost code keeps the same shape:

var maui = builder.AddMauiProject("mauiapp", "../MauiApp/MauiApp.csproj");

maui.AddMacCatalystDevice("mobile-mac");
maui.AddiOSSimulator("mobile-ios");
maui.AddAndroidEmulator("mobile-android-emulator");
maui.AddWindowsDevice("mobile-windows");

When the VS Code MAUI extension is installed, Aspire now emits structured MAUI launch metadata through DCP and the VS Code extension maps that to a type: "maui" debug configuration. IDEs that do not advertise support for the maui launch type still get the process fallback path, so this should not break Visual Studio or other IDEs.

Implementation notes:

• MAUI platform resources emit type: "maui" launch metadata with project path, target framework, platform, target kind, device/runtime metadata, and relevant MSBuild properties.
• The VS Code extension contributes the MAUI debug bridge only when ms-dotnettools.dotnet-maui is installed.
• The bridge preserves generated MAUI MSBuild properties, filters Aspire debug infrastructure environment variables, redacts MAUI environmentVariables from debug config logs, and stops late-started child MAUI sessions if the parent Aspire session is disposed.
• The E2E bridge was split out of extension.ts, and the extracted openInIntegratedBrowser command now preserves the { url } result expected by the E2E tests.

Validation:

• corepack yarn run compile-tests
• yarn run unit-test -- --config .vscode-test-short.mjs --grep "MAUI Debugger Extension Tests|E2E launch profile"
• yarn run unit-test -- --config .vscode-test-short.mjs
• corepack yarn run compile
• corepack yarn run lint
• corepack yarn run compile-e2e
• dotnet test --project tests/Aspire.Hosting.Maui.Tests/Aspire.Hosting.Maui.Tests.csproj --no-launch-profile -- --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"
• dotnet test --project tests/Aspire.Hosting.Tests/Aspire.Hosting.Tests.csproj --no-launch-profile -- --filter-method "*.MauiProjectWithExecutableAnnotationAndSupportedLaunchConfiguration_RunsInIdeWithLaunchMetadata" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17857

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17857"

[adamint]

Reviewed with four dedicated passes. I did not find any new, non-duplicate high-confidence issues to raise.

[Copilot]

Pull request overview

This PR fixes MAUI iOS simulator resource launch failures in VS Code by having the simulator resource opt out of IDE execution (via a non-"project" launch configuration type), so DCP runs it as a normal process using the ExecutableAnnotation-provided command (dotnet run). The VS Code extension no longer attempts to debug the simulator as a CoreCLR process.

Changes:

• MAUI iOS simulator resources now register a "maui-ios-simulator" debug support type that VS Code does not claim support for, causing DCP to fall through to process execution with the resource's own dotnet run command
• ExecutableCreator now honors ExecutableAnnotation on project resources (for command and working directory), and injects standard Aspire options (--configuration, --no-launch-profile) into existing dotnet run args
• The VS Code extension defers dotNetService creation until it's actually needed and extracts a shared configureDotNetRunDebugConfiguration helper

Show a summary per file

File	Description
src/Aspire.Hosting.Maui/MauiiOSExtensions.cs	Adds WithDebugSupport with "maui-ios-simulator" type so VS Code skips IDE execution
src/Aspire.Hosting/Dcp/ExecutableCreator.cs	Honors ExecutableAnnotation for command/working directory, adds AddDotnetRunArgsForExecutableAnnotatedProject helper, refactors ApplyProjectLaunchConfiguration
extension/src/debugger/languages/dotnet.ts	Defers dotNetService creation, extracts configureDotNetRunDebugConfiguration helper
extension/src/test/dotnetDebugger.test.ts	Adds test verifying ordinary project NoDebug mode uses compiled DLL path
tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs	Adds tests for custom debug support producer and ExecutableAnnotation process execution
tests/Aspire.Hosting.Maui.Tests/MauiPlatformExtensionsTests.cs	Adds test verifying iOS simulator opts out of project IDE launch while keeping SDK run args

Copilot's findings

• Files reviewed: 6/6 changed files
• Comments generated: 0

[Copilot]

Copilot's findings

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

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[karolz-ms]

Looks good but please address my suggestion before merging

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Copilot's findings

• Files reviewed: 30/31 changed files
• Comments generated: 1

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Copilot's findings

• Files reviewed: 30/31 changed files
• Comments generated: 0 new

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Copilot's findings

• Files reviewed: 30/31 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 30/31 changed files
• Comments generated: 1

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.