App Service deploy fails: cross-referencing a Foundry hosted agent from a non-Foundry resource has no resolution path

[davidfowl]

Description

aspire deploy fails when a resource deployed to App Service, Azure Container Apps, or AKS uses withReference() to reference a Foundry hosted agent. During Bicep generation, AzureAppServiceWebsiteContext.ProcessValue calls GetAppServiceContext() on every referenced resource. The hosted agent has no App Service context (it is Foundry-managed), so it throws unconditionally with no fallback. The same cross-context resolution gap exists in the ACA and AKS deployment pipelines.

Context

#16797 added support for Foundry resources referencing App Service/ACA/AKS resources (Foundry → compute targets). But the reverse direction — a compute resource deployed to App Service/ACA/AKS referencing a Foundry hosted agent — was never wired up. Cross-context reference resolution is currently one-way.

The fix likely needs to live at a shared layer (ProcessValue equivalent) across App Service, Container Apps, and AKS rather than being patched per-target.

Stack trace (from --include-exception-details)

01:01:09 (pipeline-execution) ✗ App Service context not found for resource agent-ha.
System.InvalidOperationException: App Service context not found for resource agent-ha.
   at Aspire.Hosting.Azure.AzureAppServiceEnvironmentContext.GetAppServiceContext(IResource resource)
         in AzureAppServiceEnvironmentContext.cs:line 66
   at Aspire.Hosting.Azure.AppService.AzureAppServiceWebsiteContext.ProcessValue(...)
         in AzureAppServiceWebsiteContext.cs:line 170
   at Aspire.Hosting.Azure.AppService.AzureAppServiceWebsiteContext.CreateAndConfigureWebSite(...)
         in AzureAppServiceWebsiteContext.cs:line 470
   at Aspire.Hosting.Azure.AppService.AzureAppServiceWebsiteContext.BuildWebSiteCore(...)
         in AzureAppServiceWebsiteContext.cs:line 694
   at Aspire.Hosting.Azure.AppService.AzureAppServiceWebsiteContext.BuildWebSite(...)
         in AzureAppServiceWebsiteContext.cs:line 332

Repro

AppHost (apphost.mts):

import { createBuilder, FoundryModels } from "./.aspire/modules/aspire.mjs";

const builder = await createBuilder();

const foundry = await builder.addFoundry("foundry");
const project = foundry.addProject("project");
const model = await foundry.addDeployment("chat", FoundryModels.OpenAI.Gpt4oMini);

const hostedAgent = await builder
    .addNodeApp("agent-ha", "../api", "src/server.js")
    .withHttpEndpoint({ env: "PORT" })
    .withExternalHttpEndpoints()
    .withHttpHealthCheck({ path: "/readiness" })
    .withReference(model);

await hostedAgent.asHostedAgent(project, {
    protocols: [{ protocol: "invocations", version: "1.0.0" }]
});

// This withReference crosses the Foundry boundary — triggers the failure
await builder
    .addViteApp("web", "../web")
    .withReference(hostedAgent)
    .withHttpEndpoint({ env: "PORT" });

await builder.build().run();

aspire.config.json packages:

"packages": {
    "Aspire.Hosting.JavaScript": "13.4.0",
    "Aspire.Hosting.Foundry": "13.4-*",
    "Aspire.Hosting.Azure.AppService": "13.4.0"
}

Root cause

AzureAppServiceWebsiteContext.ProcessValue (line 170) calls GetAppServiceContext() on every resource referenced via withReference(). When the referenced resource is a Foundry hosted agent (asHostedAgent()), it has no App Service context and the method throws with no fallback. The same pattern will reproduce in ACA and AKS pipelines.

Expected behavior

When a resource deployed to App Service/ACA/AKS holds a withReference() to a Foundry hosted agent, the deployment pipeline should inject the hosted agent's Foundry-published endpoint URL rather than calling GetAppServiceContext() and throwing.

Environment

• Aspire CLI: 13.4.0
• Channel: staging
• AppHost language: TypeScript
• OS: macOS Darwin arm64

[joperezr]

🤖 Aspire triage pass — 2026-05-31 09:00 UTC

Area: area-integrations (Aspire.Hosting.Azure.AppService × Aspire.Hosting.Foundry); existing area-app-model retained
Kind: bug
Repro: yes-minimal — AppHost snippet + full stack trace in issue body
Affected version(s): 13.4.0 (latest in-flight: 13.4)
Severity: S2 — App Service deploy throws InvalidOperationException with no workaround when an App Service-deployed resource .withReference()s a Foundry hosted agent

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: Failure is in AzureAppServiceWebsiteContext.ProcessValue → GetAppServiceContext on a cross-environment (Foundry hosted agent) reference. Foundry hosted agents have been actively landing through 13.4 (#17499, #17545, #17671, #17687, #17732), so this likely surfaces a new-in-13.4 combination — but I cannot confirm whether the AppService+Foundry cross-reference scenario was supported in 13.3.x at all, so per workflow guidance I'm dropping below the 13.4 release-blocking bar and flagging for human review on whether to pull into 13.4 ship.

Suggested owner(s): @eerhardt (score 4), backup @sebastienros (score 1)
Evidence:

• @eerhardt is a CODEOWNER of /src/Aspire.Hosting.Azure.AppService (with @mitchdenny) — the file paths in the stack trace (AzureAppServiceWebsiteContext.cs, AzureAppServiceEnvironmentContext.cs) live there
• @eerhardt recently merged Fix Foundry hosted agent endpoint resolution #16797 Fix Foundry hosted agent endpoint resolution and Validate environment variable names for Foundry hosted agents #16884 Validate environment variable names for Foundry hosted agents — same intersection of AppService + Foundry hosted agent endpoint resolution
• @sebastienros is the CODEOWNER of /src/Aspire.Hosting.Foundry (backup for the Foundry side of the fix)

Confidence: medium
Needs human?: yes — release-track decision (13.4 vs 13.5) on a brand-new feature-combo deploy failure with no workaround, very close to 13.4 snap

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