[Regression] Azure Functions resource fails because the generated func task type is unregistered

[adamint]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

During 1.17.0 release verification, an Azure Functions resource consistently failed after the Aspire extension called the real Azure Functions extension API.

The AppHost starts, the Functions project builds, and the Aspire extension gets Azure Functions API 1.10.0 from ms-azuretools.vscode-azurefunctions 1.22.0. startFuncProcess then creates a task named func: host start with this definition type:

func  <workspace>/AspireE2E.Functions/bin/Debug/net8.0

VS Code rejects it as an unregistered task type. The task ends immediately, the Functions host never starts, and the Aspire extension eventually reports that it could not detect the host.

The exact task-provider error was previously reported in a comment on #16997. That issue was closed after the path was expected to be fixed with 13.4, so this looks like a 13.5 regression. #18674/#18676 cover the separate func host start versus func run mismatch.

Expected Behavior

The Azure Functions resource should start through the installed Azure Functions extension, and the generated task type should have a registered provider.

Steps To Reproduce

1. Install the Aspire VS Code extension, C# extension, and Azure Functions extension.

2. Create an AppHost containing:

   var builder = DistributedApplication.CreateBuilder(args);
   builder.AddAzureFunctionsProject("functions", "../Functions/Functions.csproj");
   builder.Build().Run();

3. Run the AppHost without debugging from VS Code.

4. Open the Tasks output.

Exceptions (if any)

Error: there is no registered task type
'func  <workspace>/AspireE2E.Functions/bin/Debug/net8.0'.
Did you miss installing an extension that provides a corresponding task provider?

The Aspire extension then reports:

Azure Functions extension failed to start func host:
Failed to detect running Functions host within "30" seconds.

Aspire doctor output

Release-shaped inputs:

• Aspire VS Code extension 1.17.0, commit c66c0f80e4748e07d079e68c74dd3abf3d27a604
• Aspire CLI/AppHost 13.5.0, commit 1d922813c0f9bc14f7d817c817a8ab46b288bb44
• C# 2.148.23, darwin-arm64
• Azure Functions 1.22.0
• VS Code 1.130.0 control on macOS arm64

Anything else?

The run used a fresh hermetic NuGet cache and a locally built release hive with 103 unique Aspire package IDs, all exactly version 13.5.0. The platform-correct C# extension activated successfully, and a direct CLI control with the same package hive launched the AppHost.

ExTester cannot use the Microsoft .NET debugger in its downloaded VS Code build, so the automated control suppressed only AppHost IDE delegation. The real azure-functions capability, Azure Functions API, startFuncProcess call, generated task, CLI, hosting packages, and Functions project were unchanged.

[joperezr]

🤖 Aspire triage pass — 2026-08-12 12:20 UTC

Area: area-integrations, area-vscode
Kind: regression
Repro: yes-minimal — 4-step AppHost repro in the "Steps To Reproduce" section
Affected version(s): 13.5.0 (release/13.5, commit 1d922813); VS Code ext 1.17.0; was expected fixed in 13.4
Severity: S2 — Azure Functions resource fails to start (generated func task type is unregistered → host never launches), no workaround

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: regression surfacing in 13.5 release verification — a core Azure Functions scenario is fully broken with no workaround; clears the very-bad-bug bar for 13.5

Suggested owner(s): Ella Hathaway (@ellahathaway) (score ~4), backup Eric Erhardt (@eerhardt) (score ~1)
Evidence:

• ellahathaway merged Fix Azure Functions HTTPS launches in VS Code #19001 (Fix Azure Functions HTTPS launches in VS Code) in the last 90d — directly adjacent to this func/VS Code startup path
• CODEOWNERS lists Adam Ratzman (@adamint) Ella Hathaway (@ellahathaway) for /extension (issue author Adam Ratzman (@adamint) excluded as owner candidate)
• CODEOWNERS lists Eric Erhardt (@eerhardt) for /src/Aspire.Hosting.Azure.Functions

Confidence: medium
Needs human?: no

[ellahathaway]

A second, independent blocker surfaced while investigating this launch: DCP can pass a dotnet run separator to custom IDE project launches and advertise an invalid dotnet -- ... Process fallback. That argument-composition regression is tracked separately in #19299. Fixing the task-provider regression here may expose that failure next.