[AzureContainerAppEnvironment] Azure resource name contains too many static characters

[FSchmidt-Altus]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The name given by Aspire to resources contains too many static characters. Which means the uniqueString suffix is not applied causing issues when trying to deploy multiple environments.

Example Azure App Container:

aspire/src/Aspire.Hosting.Azure.AppContainers/AzureContainerAppExtensions.cs

Line 186 in 0e2fce7

storageVolume = new StorageAccount(Infrastructure.NormalizeBicepIdentifier($"{appEnvResource.Name}_storageVolume"))

storageVolume = new StorageAccount(Infrastructure.NormalizeBicepIdentifier($"{appEnvResource.Name}_storageVolume"))

It always adds storageVolume (13 characters) to the resource name. The maximum length of a storage volume is 24 characters. So if my chosen AddAzureContainerAppEnvironment name is 11 characters or longer then I cannot deploy multiple environments. And even when it is 10 characters long I have a high conflict probability.

Expected Behavior

Static strings applied by Aspire to resource names are as short as possible.
For example AzureContainerAppExtensions changes:

• storageVolume -> sv
• shares -> s
• managedStorage -> ms

Steps To Reproduce

Create AddAzureContainerAppEnvironment with a name of 11 characters (or more) and a volume. Try to deploy two environments. The second deployment will fail with StorageAccountAlreadyTaken.

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

$/aspire --version
13.1.0+8a4db1775c3fbae1c602022b636299cb04971fde

[MihuBot]

I'm a bot. Here are possible duplicate issues (I may be wrong):

• Multiple WithVolume calls creates naming collision when publising #11106
• Storage Volume naming blocks multiple aca environments #11270
• Generated names for azure resources with global name scope aren't always unique #13148

[FSchmidt-Altus]

It is related to #11106 as it uses also ACA and storage. The linked issue is about the usage of the storage volume to mount. This issue is about deploying the storage volume (one step before the linked issue)

Duplicate of #11270 - issue is 5 months open without any traction to such a fundamental design flaw.

[davidfowl]

@mitchdenny can you look at this? We should consider making the breaking change and let people opt into the old behavior for existing deployments.

cc @eerhardt

[mitchdenny]

Taking a look at this. The core problem is that the generated bicep names use take(staticPrefix + uniqueString(resourceGroup().id), 24) where the static prefix (user name + Aspire suffixes like storageVolume) eats the 24-char storage account budget from the left, truncating the uniqueString from the right.

For env names ≥11 chars, the unique portion is almost entirely gone. The managed storage names are even worse — managedstoragevolumesdruid (26 chars) exceeds 24 before the uniqueString, causing multiple volumes to collide with each other within the same deployment (#11106).

WithAzdResourceNaming() already fixes storage naming but also renames everything else (identity, ACR, workspace, CAE) which is too broad.

Planning to add a targeted WithCompactResourceNaming() that shortens only the length-constrained resource names by maximally preserving the full 13-char uniqueString. Will include E2E deployment tests to prove it fixes the collision and doesn't break upgrades.