Fix Azure Container App Environment to respect AsExisting and WithComputeEnvironment

[TheEagleByte]

Summary

Fixes two critical bugs preventing Azure Container App deployments from using existing Container App Environments, causing permission failures when the deployment attempted to create new infrastructure instead of referencing existing resources.

Problems Fixed

Issue #12977

1. Infrastructure Generation Ignores AsExisting Annotation

When a Container App Environment was marked with .AsExisting(), the infrastructure callback still created a brand new environment with all child resources (Container Registry, Log Analytics Workspace, User Assigned Identity, Dashboard, etc.) instead of referencing the existing environment. This caused deployment failures due to ACR access permission issues.

Location: src/Aspire.Hosting.Azure.AppContainers/AzureContainerAppExtensions.cs:60-324

2. Resource Assignment Ignores WithComputeEnvironment Binding

When multiple Container App Environments existed, resources were assigned to ALL environments instead of only their specified environment via WithComputeEnvironment(). The last environment processed would win, causing resources to be deployed to the wrong environment.

Location: src/Aspire.Hosting.Azure.AppContainers/AzureContainerAppsInfrastructure.cs:39-52

Changes Made

1. AzureContainerAppExtensions.cs - Added early-return logic in the infrastructure callback to detect ExistingAzureResourceAnnotation and call AddAsExistingResource() instead of creating new infrastructure
2. AzureContainerAppsInfrastructure.cs - Added logic to check ComputeEnvironmentAnnotation and only assign resources to their matching environment
3. ComputeEnvironmentAnnotation.cs- Made the class public (was internal) with XML documentation to allow access from theAppContainers` package
4. AzureContainerAppsTests.cs - Added comprehensive tests:

• AsExistingEnvironmentWithWithComputeEnvironmentBindsCorrectly - Validates single existing environment scenario
• MultipleEnvironmentsWithAsExistingAndWithComputeEnvironmentBindsCorrectly - Validates multiple existing environments with correct binding

Test Plan

• New tests added for both single and multiple existing environment scenarios
• Validates correct environment assignment in DeploymentTargetAnnotation
• Verifies Bicep output uses FromExisting references instead of creating new resources
• Existing Container Apps tests pass without regression (requires manual verification due to unrelated schema validation issues)

Breaking Changes

None - this is a bug fix that makes existing functionality work as documented.

Related Issues

Fixes scenarios where:

• .AsExisting(environmentName, sharedResourceGroupName) creates new infrastructure
• .WithComputeEnvironment(env) doesn't bind resources to the correct environment
• Deployments fail with ACR permission errors when using existing infrastructure

---

Note: The ComputeEnvironmentAnnotation visibility change from internal to public is intentional and necessary for the fix to work across assembly boundaries.

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-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[github-actions]

🚀 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/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12978

Or

• Run remotely in PowerShell:

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

[TheEagleByte]

@dotnet-policy-service agree

[Copilot]

Pull Request Overview

This PR fixes two critical bugs in Azure Container App deployments that prevented proper use of existing Container App Environments. The first bug caused infrastructure generation to create new resources even when AsExisting() was specified. The second bug caused resources to be assigned to all environments instead of only their specified environment when using WithComputeEnvironment().

Key changes:

• Added early-return logic to detect existing resources and skip creation of child infrastructure
• Added environment binding checks to ensure resources are only assigned to their correct environment
• Made ComputeEnvironmentAnnotation public to enable cross-assembly access
• Added comprehensive test coverage for both single and multiple existing environment scenarios

Reviewed Changes

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

File	Description
tests/Aspire.Hosting.Azure.Tests/AzureContainerAppsTests.cs	Added two new tests validating that existing environments bind correctly with AsExisting() and WithComputeEnvironment() for single and multiple environment scenarios
src/Aspire.Hosting/ApplicationModel/ComputeEnvironmentAnnotation.cs	Changed visibility from internal to public and added XML documentation to enable cross-assembly usage from AppContainers package
src/Aspire.Hosting.Azure.AppContainers/AzureContainerAppsInfrastructure.cs	Added logic to check ComputeEnvironmentAnnotation and only assign resources to their matching environment, preventing resources from being deployed to wrong environments
src/Aspire.Hosting.Azure.AppContainers/AzureContainerAppExtensions.cs	Added early-return when ExistingAzureResourceAnnotation is detected to reference existing infrastructure instead of creating new resources

[captainsafia]

This is a good start but we'll probably want to consider a different approach. This issue impacts the App Service environment as well so we'll need to make sure that works here.

Also, we'll want to test this to validate the behavior when we push new images to an existing registry and see whether everything works well with the managed identity.

Since the container app environment encapsulates multiple resources, we should figure out a way to emit the "existing" reference for each of the underlying resources. That might require us to split how we model this under the hood.