Azure Functions project fails to start when IDE cannot handle "azure-functions" launch type — DCP fallback runs bare `dotnet` with no arguments

[ascott18]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When an Azure Functions project is added via AddAzureFunctionsProject<T>() and the AppHost is launched in debug mode from VS Code without the Azure Functions extension installed, the Functions resource fails immediately with:

2026-05-12T22:31:56 Usage: dotnet [path-to-application]
2026-05-12T22:31:56 Usage: dotnet [commands]

<remainder of basic dotnet.exe help>

 [sys] run session could not be started: IDE returned a response indicating failure: Error = run session could not be started: IDE returned unexpected status code for Executable run request: 500 Internal Server Error
 [sys] An attempt to start the Executable failed: Error = the reason for the Executable startup failure is unknown
[sys] Starting process...: Cmd = C:\Program Files\dotnet\dotnet.exe, Args = []

There is no useful feedback to the developer as to why the failure happened ("the reason for the Executable startup failure is unknown") or what to do to fix it.

DCP attempts ExecutionType.IDE with the "azure-functions" launch configuration type, but when the IDE doesn't handle that type, DCP falls back to ExecutionType.Process. The fallback runs dotnet with zero arguments because run --project <path> args are only populated in the non-debug else branch of PrepareProjectExecutables() in ExecutableCreator.cs.

The first two branches (SupportsDebugging == true and ShouldFallBackToIdeExecution) set FallbackExecutionTypes = [Process] but leave projectArgs empty, assuming the IDE will handle launching. When the IDE can't handle "azure-functions", the fallback inherits empty args.

Expected Behavior

When DCP falls back from IDE to Process execution for an "azure-functions" launch type, it should construct valid process arguments (e.g. dotnet run --project <path>) so the Functions project can start without IDE-assisted launching.

It should also perhaps detect and produce warnings about the missing VS code extension if at all possible.

Steps To Reproduce

1. Create an Aspire AppHost with an Azure Functions isolated worker project using FunctionsApplication.CreateBuilder(args)
2. Use AddAzureFunctionsProject<T>("functions") in AppHost.cs
3. Open in VS Code with C# Dev Kit (without Azure Functions extension)
4. Press F5 (Start Debugging) on the AppHost
5. Observe the Functions resource immediately exits with dotnet CLI usage help

Workaround: Run without debugging (Ctrl+F5) or dotnet run from terminal.

Exceptions (if any)

No response

Aspire doctor output

No response

Anything else?

• .NET SDK: 10.0.203
• IDE: VS Code with C# Dev Kit
• OS: Windows 11
• Aspire: 13.2.4
• Azure Functions Worker SDK: 2.0.4
• azure-functions-core-tools: 4.10.0

Relevant source:

• ExecutableCreator.cs — PrepareProjectExecutables()
• AzureFunctionsProjectResourceExtensions.cs — WithDebugSupport(..., "azure-functions")

[joperezr]

🤖 Aspire triage pass — 2026-05-13 02:45 UTC

Area: area-tooling (existing), area-integrations, area-orchestrator
Kind: bug
Repro: yes-minimal — clear repro steps in the issue body (Steps To Reproduce section)
Affected version(s): 13.2.4 (current servicing track: 13.3.x; vNext: 13.4)
Severity: S3 — Azure Functions startup broken in a specific IDE configuration (VS Code without Azure Functions extension); workaround exists (Ctrl+F5 / dotnet run from terminal)

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: clean bug report with code paths identified (ExecutableCreator.PrepareProjectExecutables() fallback branch leaves projectArgs empty); S3 with workaround; not a recent regression baseline-able to 13.3.

Suggested owner(s): Eric Erhardt (@eerhardt)
Evidence:

• CODEOWNERS lists Eric Erhardt (@eerhardt) for /src/Aspire.Hosting.Azure.Functions/** (cited file AzureFunctionsProjectResourceExtensions.cs verified to exist at that path)
• The other cited file (ExecutableCreator.cs) is in DCP/orchestrator territory; CODEOWNERS for /src/Aspire.Hosting lists James Newton-King (@JamesNK) Karol Zadora-Przylecki (@karolz-ms) David Negstad (@danegsta) Mitch Denny (@mitchdenny) David Fowler (@davidfowl) — Eric Erhardt (@eerhardt) is the clearest single owner since the bug originates in the Azure Functions integration's debug launch wiring (WithDebugSupport(..., "azure-functions"))
• No non-bot merged-PR signal in area-integrations / area-orchestrator in the last 90d to add weight

Confidence: medium
Needs human?: no

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[davidfowl]

Aspire: 13.2.4

Update to 13.3.1

[ascott18]

Sorry about that - same error on 13.3.1.

The issue also occurs with Visual Studio. Same apparent issue in the logging output - it tries to run dotnet.exe with no arguments whatsoever. Output below is the same between VS Code and Visual Studio.

2026-05-12T22:31:54 Waiting for resource 'storage' to enter the 'Running' state.
2026-05-12T22:31:55 Waiting for resource 'storage' to become healthy.
2026-05-12T22:31:55 Waiting for resource ready to execute for 'storage'.
2026-05-12T22:31:55 Finished waiting for resource 'storage'.
2026-05-12T22:31:56  
2026-05-12T22:31:56 Usage: dotnet [path-to-application]
2026-05-12T22:31:56 Usage: dotnet [commands]
2026-05-12T22:31:56  
2026-05-12T22:31:56 path-to-application:
2026-05-12T22:31:56   The path to an application .dll file to execute.
2026-05-12T22:31:56  
2026-05-12T22:31:56 commands:
2026-05-12T22:31:56   -h|--help                         Display help.
2026-05-12T22:31:56   --info                            Display .NET information.
2026-05-12T22:31:56   --list-runtimes [--arch <arch>]   Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
2026-05-12T22:31:56   --list-sdks [--arch <arch>]       Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.
 [sys] run session could not be started: IDE returned a response indicating failure: Error = run session could not be started: IDE returned unexpected status code for Executable run request: 500 Internal Server Error
 [sys] An attempt to start the Executable failed: Error = the reason for the Executable startup failure is unknown
[sys] Starting process...: Cmd = C:\Program Files\dotnet\dotnet.exe, Args = []

[ascott18]

Additionally as I found out a bit later while working through this issue, once I do enable the Azure Functions VS Code extension, I then get this error on every launch, which crashes the whole debug session including the app host.

I then see this in the Tasks output in VS Code:

Activating task providers all
Activating task providers all
Error: there is no registered task type 'func  D:\PhotoApp\PhotoApp.Functions\bin\Debug\net10.0'. Did you miss installing an extension that provides a corresponding task provider?

I'm not sure how to get any more detail about that error, or even how to tell if its Aspire's problem or VS Code's problem or the Azure Functions extensions' problem.

I am able to get everything running with the Aspire extension and the Azure Functions extension and the aspire launch type. However, debugging does not work in my Functions - breakpoints show in the IDE like they're bound, but they're never hit.

[ascott18]

Ok, I'm finding some more things out that may or may not be related.

If you launch the Aspire host purely with dotnet run, no IDE or debugger involved, and you've installed the Azure Functions Core tools via npm i -g azure-functions-core-tools, you get the following error because the func on the path is not a .exe, but rather resolves to a .bat or .ps1 depending on shell, with no func.exe on the PATH at all. Since the orchestrator is not launching with ShellExec, it fails to launch:

2026-05-12T23:37:33 Waiting for resource 'storage' to enter the 'Running' state.
2026-05-12T23:37:33 Waiting for resource 'storage' to become healthy.
2026-05-12T23:37:33 Waiting for resource ready to execute for 'storage'.
2026-05-12T23:37:33 Finished waiting for resource 'storage'.
2026-05-12T23:37:34  Unhandled exception: An error occurred trying to start process 'func' with working directory 'bin\Debug\net10.0\'. The system cannot find the file specified.
[sys] Starting process...: Cmd = C:\Program Files\dotnet\dotnet.exe, Args = ["run", "--project", "D:\\PhotoApp\\PhotoApp.Functions\\PhotoApp.Functions.csproj", "--no-build", "--configuration", "Debug", "--no-launch-profile", "--port", "7194"]

On the other hand, if you use an install that gets you an .exe on your path (e.g. via winget), and then launch via CLI, then you don't get the above error, and everything works OK.

But again, the above only deals with the no-debugger, no IDE launch of the Aspire host. It probably deserves a separate issue of its own, but I just discovered it and thought that it could be related, e.g. maybe the lack of a proper func.exe is what is actually triggering the fallback behavior to occur in the first place? Or maybe its the cause of the issue in my previous comment?

[davidfowl]

VS code VS and launching from the command line all work differently (for now). Something we intend to improve but lets focus on this issue and VS code.

[joperezr]

This looks potentially related to #17015 — both exhibit the same execution behavior where DCP falls back to launching dotnet.exe with empty (or near-empty) arguments after the IDE-mediated launch path doesn't succeed, producing the cryptic dotnet usage banner instead of a clear error.

In #17015 the trigger is VS 18.6.0 returning 500 to DCP's executable-run request; here the trigger is an IDE that can't handle the azure-functions launch type. Different upstream causes, but the same failure mode in the fallback path. Worth fixing the fallback to either run with the correct project args or surface a clearer error instead of bare dotnet.

[adamint]

Ok, I'm finding some more things out that may or may not be related.

If you launch the Aspire host purely with dotnet run, no IDE or debugger involved, and you've installed the Azure Functions Core tools via npm i -g azure-functions-core-tools, you get the following error because the func on the path is not a .exe, but rather resolves to a .bat or .ps1 depending on shell, with no func.exe on the PATH at all. Since the orchestrator is not launching with ShellExec, it fails to launch:

2026-05-12T23:37:33 Waiting for resource 'storage' to enter the 'Running' state.
2026-05-12T23:37:33 Waiting for resource 'storage' to become healthy.
2026-05-12T23:37:33 Waiting for resource ready to execute for 'storage'.
2026-05-12T23:37:33 Finished waiting for resource 'storage'.
2026-05-12T23:37:34  Unhandled exception: An error occurred trying to start process 'func' with working directory 'bin\Debug\net10.0\'. The system cannot find the file specified.
[sys] Starting process...: Cmd = C:\Program Files\dotnet\dotnet.exe, Args = ["run", "--project", "D:\\PhotoApp\\PhotoApp.Functions\\PhotoApp.Functions.csproj", "--no-build", "--configuration", "Debug", "--no-launch-profile", "--port", "7194"]

On the other hand, if you use an install that gets you an .exe on your path (e.g. via winget), and then launch via CLI, then you don't get the above error, and everything works OK.

But again, the above only deals with the no-debugger, no IDE launch of the Aspire host. It probably deserves a separate issue of its own, but I just discovered it and thought that it could be related, e.g. maybe the lack of a proper func.exe is what is actually triggering the fallback behavior to occur in the first place? Or maybe its the cause of the issue in my previous comment?

I'm able to reproduce this too.

[yuukitakeuchi]

I ran into the same issue in VisualStudio2026 (It was working last week, but somehow...

For me, .NET 10 was no longer selectable as a target framework when create new Azure Functions project. However, updating and then deleting old toolset the Functions toolset and template in the Visual Studio options, resolved the problem.