Fix 13.2 IDE execution regressions for Azure Functions and class library projects by adamint · Pull Request #15714 · microsoft/aspire

adamint · 2026-03-30T20:24:07Z

Description

Fixes regressions introduced in Aspire 13.2 where project resources using custom debug types (Azure Functions, AWS Lambda class libraries) or added via AddResource without WithDebugSupport no longer received IDE execution in Visual Studio or VS Code, breaking debugging and symbol loading.

In DcpExecutor.PrepareProjectExecutables(), adds a fallback branch that provides IDE execution with a standard ProjectLaunchConfiguration when in a debug session but either no SupportsDebuggingAnnotation exists (e.g. AddResource-based ProjectResource subclasses) or the IDE did not send DEBUG_SESSION_INFO (Visual Studio scenario where VS handles all project types natively). This restores pre-13.2 behavior.

In the VS Code extension, adds support for Executable command launch profiles used by AWS Lambda. When the launch profile specifies commandName: "Executable" with an executablePath, the extension builds the project and uses the profile's executable path as the debug program instead of the project output DLL.

Includes a ProjectResourceExtensions playground app for manual E2E validation of standard, custom-debug, Azure Functions, and class library project types.

Fixes #15606
Fixes #15647
Fixes #15378
Fixes #15699

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
Does the change require an update in our Aspire docs?
- Yes
  - Link to aspire.dev issue:
    - New issue
- No

github-actions · 2026-03-30T20:24:23Z

🚀 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 -- 15714

Or

Run remotely in PowerShell:

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

…rojects - ExtensionUtils: treat 'project' launch type as implicitly supported by DCP, so standard projects get IDE execution even when VS Code extension sends SupportedLaunchConfigurations without 'project' (microsoft#15606, microsoft#15647) - DcpExecutor: add else-if branch for VS scenario (DEBUG_SESSION_PORT set, no DEBUG_SESSION_INFO) so projects with non-'project' annotations like 'azure-functions' still get IDE execution with ProjectLaunchConfiguration fallback (microsoft#15378) - Add 8 unit tests covering VS, VS Code, and CLI scenarios - Add IdeDebuggingRepro playground for manual verification

…rojects - ExtensionUtils: treat 'project' launch type as implicitly supported by DCP, so standard projects get IDE execution even when VS Code extension sends SupportedLaunchConfigurations without 'project' (microsoft#15606, microsoft#15647) - DcpExecutor: add else-if branch for VS scenario (DEBUG_SESSION_PORT set, no DEBUG_SESSION_INFO) so projects with non-'project' annotations like 'azure-functions' still get IDE execution with ProjectLaunchConfiguration fallback (microsoft#15378). Also handles ProjectResource subclasses added via AddResource without WithDebugSupport (e.g. AWS Lambda) (microsoft#15606) - Extension dotnet.ts: handle Executable command launch profiles (e.g. AWS Lambda) by using the profile's executablePath instead of the project output DLL, which fails for class library projects (microsoft#15647) - Add 10 hosting unit tests covering VS, VS Code, and CLI scenarios - Add extension test for Executable launch profile handling - Add IdeDebuggingRepro playground for manual verification

- Add FakeIntegrationLibrary class-library project with Executable launch profile - Add fake ProjectResource subclass integration added via AddResource (no WithDebugSupport) - Wire fake integration into IdeDebuggingRepro.AppHost for manual validation of: - microsoft#15606 (ProjectResource subclass without debug annotation) - microsoft#15647 (Executable launch profile handling in VS Code extension) - microsoft#15378 (existing custom non-project debug type scenario remains)

- Rename playground folder and AppHost project to ProjectResourceExtensions - Add AzureFunctionsService to validate VS Azure Functions debugging scenario (microsoft#15378) - Keep fake ProjectResource subclass integration and Executable launch-profile scenario for microsoft#15606 and microsoft#15647 manual E2E validation - Validate renamed AppHost builds successfully

The class library OutputType caused VS to hang — DCP sets ExecutionType.IDE but VS can't launch a Library project and doesn't report failure, so DCP waits indefinitely. Changed to Web SDK with a minimal Program.cs endpoint.

The empty {} caused the CLI/AppHost to fail because ASPNETCORE_URLS and ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL were never set.

Both custom-debug-service and fake-integration-library defaulted to port 5000 since no endpoints were declared. Adding WithHttpEndpoint() lets DCP assign dynamic ports.

AddResource doesn't call WithProjectDefaults, so ASPNETCORE_URLS was never set and the app defaulted to port 5000. Added environment callback to inject URLs from allocated endpoints, matching what AddProject does.

AddProject already creates a default http endpoint, so the extra WithHttpEndpoint() caused a name collision.

…x port binding - Move funcApp declaration before standardService to fix use-before-declare - StandardService now references funcApp and exposes /call-functions endpoint - FakeIntegrationLibrary reads PORT env var for dynamic port binding - Add ServiceDefaults to StandardService for service discovery

Without launch profiles, Kestrel defaults to port 5000 which conflicts with macOS AirPlay. Setting applicationUrl to port 0 lets the OS assign a free port, and DCP overrides with ASPNETCORE_URLS when orchestrating.

- Fix != null to is not null in two test methods - Add FallbackExecutionTypes assertions to fallback branch tests - Add ProjectLaunchConfiguration assertion to VS scenario test - Revert unintended xlf whitespace change Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Fixes Aspire 13.2 regressions where certain project resources (custom debug types like Azure Functions / AWS Lambda class libraries, or AddResource-based ProjectResource subclasses without debug annotations) stopped getting IDE execution, breaking debugging/symbol loading in Visual Studio and VS Code.

Changes:

Restores IDE execution fallback behavior in DcpExecutor.PrepareProjectExecutables() for debug sessions when debug annotations are missing or when VS does not provide DEBUG_SESSION_INFO.
Updates the VS Code extension to support commandName: "Executable" launch profiles (e.g., AWS Lambda) by launching via executablePath instead of the project output DLL.
Adds targeted unit tests and a playground app for manual E2E validation of standard/custom/Azure Functions/class-library project cases.

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs	Adds/adjusts tests covering implicit `"project"` support, VS fallback behavior, and process fallback guards.
src/Aspire.Hosting/Utils/ExtensionUtils.cs	Treats `"project"` launch configuration as implicitly supported in debug sessions.
src/Aspire.Hosting/Dcp/DcpExecutor.cs	Adds IDE execution fallback branch to restore pre-13.2 behavior for projects in debug sessions.
extension/src/debugger/languages/dotnet.ts	Supports `Executable` launch profiles by using `executablePath` as the launched program (and building the project).
extension/src/test/dotnetDebugger.test.ts	Adds test coverage for `Executable` launch profile handling.
playground/ProjectResourceExtensions/**	Adds a manual validation playground solution and sample projects.
Aspire.slnx	Includes the new playground projects in the repo solution index.

playground/ProjectResourceExtensions/ProjectResourceExtensions.AppHost/AppHost.cs

extension/src/debugger/languages/dotnet.ts

playground/ProjectResourceExtensions/ProjectResourceExtensions.sln

src/Aspire.Hosting/Dcp/DcpExecutor.cs

- Remove unused standardService variable (CS0219) - Add LaunchProfileCommandName consts with case-insensitive comparisons - Remove unnecessary playground .sln file - Extract ShouldFallBackToIdeExecution() method for readability - Extract CreateProjectLaunchConfiguration() to deduplicate code - Clarify comment about non-project launch config timing

When a launch profile uses commandName=Executable with executablePath=dotnet and commandLineArgs starting with 'exec', the coreclr debugger needs the target DLL as the program, not 'dotnet' itself. Parse the exec args to extract the DLL path and application arguments so the debugger can properly attach to Lambda class library functions.

For class library Lambda projects with commandName=Executable launch profiles, skip IDE execution and use process execution with the launch profile's command line args (dotnet exec ...) directly. This avoids the issue where the coreclr debugger can't attach to a bare 'dotnet' host. Also reverts the parseDotnetExecArgs approach in the extension since these resources now run as processes rather than IDE-debugged sessions.

Two new tests: - ProjectExecutable_NoAnnotation_ExecutableLaunchProfile_InDebugSession_RunsInProcessWithExecArgs: Verifies class library Lambda projects with Executable launch profiles get process execution with dotnet exec args - ProjectExecutable_NoAnnotation_ProjectLaunchProfile_InDebugSession_RunsInIdeMode: Verifies normal Project launch profiles still get IDE execution

…tion

Remove arg parsing and variable expansion complexity. Instead, simply exclude Executable command name profiles from IDE fallback in ShouldFallBackToIdeExecution(), letting them fall through to the standard process execution path (dotnet run). Also remove AWS-specific language from all comments.

- Fix logical bug: determineWorkingDirectory now expands env vars (e.g. $(HOME)) before checking path.isAbsolute, preventing incorrect relative path resolution - Fix inaccurate JSDoc on expandEnvironmentVariables (remove $VAR claim) - Fix misleading comment about always using launch profile args - Fix test comment grammar - Add integration test for env var expansion in Executable profile paths - Add negative assertion for empty project args in IDE fallback test - Add tests for env var expansion in working directory resolution Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

adamint · 2026-04-01T06:40:05Z

I discovered a couple additional issues related to args handling in the vs code extension and behavior existing in VS that we should be replicating in VS Code (environment variable expansion).

I've tested these fixes with azure functions projects, lambda projects, and normal projects in both VS Code and VS as well as the CLI.

… Functions and class library projects (microsoft#15714)

… Functions and class library projects (#15714) (#15763)

adamint force-pushed the dev/adamint/dcpexecutor-bugs branch from 679f3a1 to 35242ef Compare March 31, 2026 17:22

adamint changed the title ~~test~~ fix 13.2 projectresource subclass regressions Mar 31, 2026

adamint and others added 15 commits March 31, 2026 15:07

Add ProjectResourceExtensions playground to solution

a500713

change output type to executable

f096369

Remove leftover Class1.cs from FakeIntegrationLibrary

5a1e10d

Fix AppHost launchSettings.json with proper profiles

7528237

The empty {} caused the CLI/AppHost to fail because ASPNETCORE_URLS and ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL were never set.

Add HTTP endpoints to playground resources to avoid port 5000 collision

7a7268f

Both custom-debug-service and fake-integration-library defaulted to port 5000 since no endpoints were declared. Adding WithHttpEndpoint() lets DCP assign dynamic ports.

Fix fake integration AddResource: inject ASPNETCORE_URLS from endpoints

fb705ca

AddResource doesn't call WithProjectDefaults, so ASPNETCORE_URLS was never set and the app defaulted to port 5000. Added environment callback to inject URLs from allocated endpoints, matching what AddProject does.

Remove duplicate WithHttpEndpoint on custom-debug-service

51e7945

AddProject already creates a default http endpoint, so the extra WithHttpEndpoint() caused a name collision.

Add launchSettings.json to StandardService and CustomDebugService

7192f90

Without launch profiles, Kestrel defaults to port 5000 which conflicts with macOS AirPlay. Setting applicationUrl to port 0 lets the OS assign a free port, and DCP overrides with ASPNETCORE_URLS when orchestrating.

adamint force-pushed the dev/adamint/dcpexecutor-bugs branch from d598a1d to 72da4f1 Compare March 31, 2026 19:09

adamint changed the title ~~fix 13.2 projectresource subclass regressions~~ Fix IDE execution regressions for Azure Functions, AWS Lambda, and class library projects Mar 31, 2026

adamint changed the title ~~Fix IDE execution regressions for Azure Functions, AWS Lambda, and class library projects~~ Fix 13.2 IDE execution regressions for Azure Functions and class library projects Mar 31, 2026

adamint marked this pull request as ready for review March 31, 2026 20:09

adamint requested a review from mitchdenny as a code owner March 31, 2026 20:09

Copilot AI review requested due to automatic review settings March 31, 2026 20:09

adamint requested review from JamesNK, danegsta, davidfowl and karolz-ms as code owners March 31, 2026 20:09

Copilot started reviewing on behalf of adamint March 31, 2026 20:11 View session

Copilot AI reviewed Mar 31, 2026

View reviewed changes

playground/ProjectResourceExtensions/ProjectResourceExtensions.AppHost/AppHost.cs Outdated Show resolved Hide resolved

github-actions bot mentioned this pull request Mar 31, 2026

[pull requests] Review required #13834

Open

danegsta approved these changes Mar 31, 2026

View reviewed changes

adamint mentioned this pull request Apr 1, 2026

Fix issue with Lambda functions failing to start when launched in Visual Studio aws/integrations-on-dotnet-aspire-for-aws#168

Closed

karolz-ms approved these changes Apr 1, 2026

View reviewed changes

JamesNK reviewed Apr 1, 2026

View reviewed changes

adamint mentioned this pull request Apr 1, 2026

[release/13.2] Fix 13.2 IDE execution regressions for Azure Functions and class library projects #15740

Closed

JamesNK approved these changes Apr 1, 2026

View reviewed changes

adamint mentioned this pull request Apr 1, 2026

[release/13.2] Fix 13.2 IDE execution regressions for Azure Functions and class library projects #15741

Closed

adamint added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 1, 2026

adamint and others added 6 commits March 31, 2026 23:57

Fix potential null dereference on commandName in launch profile itera…

5b27c05

…tion

adamint removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 1, 2026

adamint requested review from JamesNK and karolz-ms April 1, 2026 13:41

karolz-ms approved these changes Apr 1, 2026

View reviewed changes

adamint added a commit to adamint/aspire that referenced this pull request Apr 1, 2026

[release/13.2] Backport: Fix 13.2 IDE execution regressions for Azure…

01333df

… Functions and class library projects (microsoft#15714)

adamint mentioned this pull request Apr 1, 2026

[release/13.2] Backport: Fix 13.2 IDE execution regressions for Azure Functions and class library projects (#15714) #15763

Merged

10 tasks

adamint merged commit ca9e837 into microsoft:main Apr 1, 2026
256 checks passed

karolz-ms added a commit that referenced this pull request Apr 1, 2026

Re-apply PR #15714 changes

ee3a9a5

joperezr pushed a commit that referenced this pull request Apr 3, 2026

[release/13.2] Backport: Fix 13.2 IDE execution regressions for Azure…

46a37df

… Functions and class library projects (#15714) (#15763)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix 13.2 IDE execution regressions for Azure Functions and class library projects#15714

Fix 13.2 IDE execution regressions for Azure Functions and class library projects#15714
adamint merged 22 commits intomicrosoft:mainfrom
adamint:dev/adamint/dcpexecutor-bugs

adamint commented Mar 30, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Mar 30, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adamint commented Apr 1, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

adamint commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

github-actions bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adamint commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

adamint commented Mar 30, 2026 •

edited

Loading

github-actions bot commented Mar 30, 2026 •

edited

Loading

adamint commented Apr 1, 2026 •

edited

Loading