Azure Container App Environment with AsExisting() creates new infrastructure instead of using existing resources

[TheEagleByte]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using .AsExisting() to reference an existing Azure Container App Environment, the deployment still creates a brand new environment with all child resources (Container Registry, Log Analytics Workspace, User Assigned Identity, Dashboard, etc.) instead of using the existing environment reference. This causes deployment failures due to permission issues when trying to create resources that already exist or when the deployment identity lacks permissions to create new infrastructure.

Additionally, when multiple Container App Environments are defined, the WithComputeEnvironment() binding is ignored, and resources are assigned to all environments instead of only their specified environment.

Expected Behavior

When a Container App Environment is marked with .AsExisting(environmentName, resourceGroupName):

• The generated Bicep should use ContainerAppManagedEnvironment.FromExisting() to reference the existing environment
• No new child resources (ACR, LAW, Identity, etc.) should be created
• Container Apps should reference the existing environment's ID

When WithComputeEnvironment(env) is used:

• Resources should only be assigned to the specified environment
• Resources should not be assigned to other environments in the application

Steps To Reproduce

Using the latest .NET 10 SDK and Aspire 13.0.0 nuget packages:

using Aspire.Hosting.Azure;

var builder = DistributedApplication.CreateBuilder(args);

var registryName = builder.AddParameter("registryName");
var sharedResourceGroupName = builder.AddParameter("sharedResourceGroupName");
var environmentName = builder.AddParameter("environmentName");

var acr = builder.AddAzureContainerRegistry("acr")
    .AsExisting(registryName, sharedResourceGroupName);

var mid = builder.AddAzureUserAssignedIdentity("mid")
    .WithRoleAssignments(acr, ContainerRegistryBuiltInRole.AcrPull);

var containerAppEnv = builder
    .AddAzureContainerAppEnvironment("env")
    .AsExisting(environmentName, sharedResourceGroupName)
    .WithAzureContainerRegistry(acr)
    .ConfigureInfrastructure(infra =>
    {
        // Remove auto-created identity and use our own
        var identity = infra.GetProvisionableResources().OfType<UserAssignedIdentity>().Single();
        infra.Remove(identity);

        var roleAssignment = infra.GetProvisionableResources().OfType<RoleAssignment>().Single();
        infra.Remove(roleAssignment);

        var managedIdentity = infra.GetProvisionableResources()
            .OfType<ProvisioningOutput>()
            .Single(r => r.BicepIdentifier == "AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID");
        infra.Remove(managedIdentity);

        infra.Add(new ProvisioningOutput("AZURE_CONTAINER_REGISTRY_MANAGED_IDENTITY_ID", typeof(string))
        {
            Value = mid.Resource.Id.AsProvisioningParameter(infra)
        });
    });

var mcpServer = builder
    .AddProject<Projects.MyProject>("mcp-server")
    .WithExternalHttpEndpoints()
    .WithComputeEnvironment(containerAppEnv)  // This is ignored
    .PublishAsAzureContainerApp((_, _) => { });

builder.Build().Run();

Executing the following during CI/CD Deployment:

curl -sL https://aka.ms/InstallAzureCLIDeb | bash

az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET --tenant $AZURE_TENANT_ID
az account set --subscription $AZURE_SUBSCRIPTION_ID

az bicep upgrade

az acr login --name $AZURE_ACR_NAME

dotnet tool install -g Aspire.Cli --version 13.0.0 || dotnet tool update -g Aspire.Cli --version 13.0.0
export PATH="$PATH:/root/.dotnet/tools"
aspire config set features.deployCommandEnabled true

# Set defaults for my new infrastructure
export Azure__SubscriptionId=$AZURE_SUBSCRIPTION_ID
export Azure__Location=$AZURE_LOCATION
export Azure__ResourceGroup=$AZURE_RESOURCE_GROUP

# Pass in shared parameters for existing infrastructure
aspire deploy \
  --project MyProject.AppHost/MyProject.AppHost.csproj \
  --output-path deployment-artifacts \
  --parameter registryName=$PARAMETERS__REGISTRYNAME \
  --parameter sharedResourceGroupName=$PARAMETERS__SHAREDRESOURCEGROUPNAME \
  --parameter environmentName=$PARAMETERS__ENVIRONMENTNAME

Result:

• Deployment attempts to create a new Container App Environment with new ACR, LAW, Identity
• Deployment fails with permission errors trying to access or create the ACR
• The container app is not deployed to the existing environment

Note:
The above workaround is used currently due to this issue: #11256 (comment)

Exceptions (if any)

N/A

.NET Version info

.NET SDK:
 Version:           10.0.100
 Commit:            b0f34d51fc
 Workload version:  10.0.100-manifests.4c0ca8ba
 MSBuild version:   18.0.2+b0f34d51f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0
  Architecture: x64
  Commit:       b0f34d51fc

.NET SDKs installed:
  6.0.401 [C:\Program Files\dotnet\sdk]
  6.0.428 [C:\Program Files\dotnet\sdk]
  7.0.100 [C:\Program Files\dotnet\sdk]
  7.0.120 [C:\Program Files\dotnet\sdk]
  8.0.206 [C:\Program Files\dotnet\sdk]
  8.0.416 [C:\Program Files\dotnet\sdk]
  9.0.306 [C:\Program Files\dotnet\sdk]
  10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.31 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.31 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.31 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

Anything else?

Root Causes:

1. Infrastructure Generation (AzureContainerAppExtensions.cs:60-324): The infrastructure callback always creates a new ContainerAppManagedEnvironment with all child resources, even when ExistingAzureResourceAnnotation is present. It should check for the annotation and call AddAsExistingResource() instead.
2. Resource Assignment (AzureContainerAppsInfrastructure.cs:39-52): The code processes all compute resources for each environment without checking the ComputeEnvironmentAnnotation, causing resources to be assigned to all environments instead of just their specified one.

Impact:

• Blocks usage of existing Azure infrastructure
• Forces creation of duplicate resources
• Causes permission failures in restricted environments
• Makes it impossible to use pre-configured Container App Environments with specific networking, security, or compliance requirements

Workaround:
Currently there is no workaround - the functionality to use existing Container App Environments is broken.

[captainsafia]

Additionally, when multiple Container App Environments are defined, the WithComputeEnvironment() binding is ignored, and resources are assigned to all environments instead of only their specified environment.

We should file a new issue to track this one. I suspect WithComputeEnvironment isn't handling the "multiple compute environments of the same type case" correctly.

The AsExisting issue will be interesting to fix. Breaking up the Bicep we generate for the ACA environment might help make this easier and lines up with what we are wanting to do to support faster deployments anyway. Right now, there's no way for you to control from the resource model the Log Analytics and other resources that are associated with the environment.

[TheEagleByte]

@captainsafia I filed this issue and @davidfowl mentioned it is a duplicate of #9094 which is back from May.