Skip to content

Tracking: Complete the end-to-end Aspire experience in VS Code #19405

Description

@adamint

Goal

Make the Aspire extension for VS Code a complete default environment for the full Aspire developer loop: create or initialize an app, run it, debug it, test it, inspect it, manage resources, and deploy it across local, remote, C#, and polyglot workspaces.

The extension already has strong AppHost run/debug support, a live resource tree, AppHost CodeLens, dashboard integration, resource commands, Aspire CLI integration, and automatic Aspire MCP registration. The remaining work is primarily about making complete user journeys reliable, discoverable, and consistent.

This is an outcome-oriented tracker. It complements #19066, which tracks the operational queue of open extension issues and active pull requests.

Exit criteria

Setup and project creation

  • A new user can install or locate the Aspire CLI, create or initialize a project, and start the correct AppHost without environment-specific troubleshooting.
  • Version or capability mismatches identify the installed components, the unsupported capability, and a concrete remediation.
  • Enterprise package-source configuration works consistently for CLI and editor-driven template and package operations.
  • Project creation validates destination conflicts before generation begins.

Workspace and AppHost identity

  • Single-root, multi-root, nested-repository, and linked-worktree workspaces resolve the intended AppHost consistently.
  • Ambiguous workspaces prompt for an AppHost instead of guessing or failing inside a non-interactive launch.
  • The selected AppHost is shared by F5, editor actions, the Aspire pane, lifecycle tools, and command-palette operations.

Run and debug

  • Supported AppHost and resource debugger settings are honored.
  • Users can attach supported debuggers to eligible resources in an already-running AppHost.
  • Missing debugger dependencies produce actionable install guidance rather than silently running without a debugger.
  • Debug output is readable, correctly classified, and not duplicated.
  • Per-language launch, attach, breakpoint, and teardown behavior has end-to-end coverage.

Deployment and pipelines

  • Deploy, publish, and pipeline operations are discoverable from the AppHost in the Aspire pane.
  • Inputs use the Aspire interaction service, progress and output stay visible, cancellation is clean, and the extension delegates execution to the Aspire CLI.

Remote and polyglot workflows

  • Remote SSH, Dev Containers, WSL, and Codespaces have a defined and validated AppHost discovery, CLI, dashboard, debugger, and teardown model.
  • Java resources can participate in the supported resource-debugging workflow after the Java hosting integration is available.

Reliability

  • Blocking end-to-end coverage protects onboarding, AppHost discovery, launch, per-language debugging, resource actions, dashboard behavior, and teardown.
  • Failures are classified with enough information to distinguish extension regressions, external debugger failures, and infrastructure failures.

Scope

  • Reuse the Aspire CLI, dashboard, interaction service, resource commands, and Aspire MCP server rather than duplicating those systems in the extension.
  • Add editor-native entry points for common workflows while preserving terminal and launch.json configuration for advanced scenarios.
  • Keep target-specific deployment configuration in the AppHost and Aspire deployment pipeline.
  • Track generic editor or language-extension work here only when Aspire requires integration or lifecycle coordination.

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions