"Better Azure resource name scheme" breaks existing deployments

[Steinblock]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

See breaking changes: https://learn.microsoft.com/en-us/dotnet/aspire/compatibility/9.0/azure-resource-name-scheme

After upgrading my project from aspire 8.2 to 9.0 and deploying to azure with azd up I found my postgres and servicebus resources had been duplicated.

Old:

• postgres78wllqae8plh7
• messaging78wllqae8plh7

New:

• postgres-78wllqae8plh7
• messaging-78wllqae8plh7

Other resources already had the name-id naming scheme

• cae-78wllqae8plh7 (Container apps environment)
• law-78wllqae8plh7 (Log analytics workspace)
• mi-78wllqae8plh7 (Managed identity)

While others still use the nameid naming scheme even after azd up

• acr78wllqae8plh7 (Container registry)
• storage78wllqae8plh7 (Storage account)

In the link provided there is solution for me to use my old resources.

builder.Services.Configure<AzureProvisioningOptions>(options =>
{
    options.ProvisioningBuildOptions.InfrastructureResolvers.Insert(0, new AspireV8ResourceNamePropertyResolver());
});

Having a consistent naming scheme is great but since the resources get tagged with aspire-resource-name and the storage resource kept the old naming schema I think that it is intended to be handled automatically but fails for postgres and servicebus.

Expected Behavior

my existing resource group should keep the existing AspireV8 naming schema but new resources I deploy in this resource group or other resource groups can use the new naming schema without requiring me to add

builder.Services.Configure<AzureProvisioningOptions>(options =>
{
    options.ProvisioningBuildOptions.InfrastructureResolvers.Insert(0, new AspireV8ResourceNamePropertyResolver());
});

Steps To Reproduce

Create a new Aspire project with aspire 8.2 or earlier with

• a servicebus resource

var serviceBus = builder.AddAzureServiceBus("messaging");

• a storage account

var storage = builder.AddAzureStorage("storage");

• publish the project to azure with azd up

• after publish verify that the created resources (storage... and servicebus...) don't have a minus between the resource name and the id.

• upgrade to aspire 9

• publish again

• now the storage account will still be named storageid but the servicebus resource will be duplicated and the new servicebus-id will be used.

Exceptions (if any)

No response

.NET Version info

.NET SDK:
Version: 9.0.100
Commit: 59db016f11
Workload version: 9.0.100-manifests.c6f19616
MSBuild version: 17.12.7+5b8665660

Laufzeitumgebung:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.100\

Installierte .NET-Workloads:
[aspire]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 8.2.2/8.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Installationstyp: Msi

[maui-windows]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 9.0.0/9.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.0\WorkloadManifest.json
Installationstyp: Msi

[maccatalyst]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 18.0.9617/9.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.0.9617\WorkloadManifest.json
Installationstyp: Msi

[ios]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 18.0.9617/9.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.0.9617\WorkloadManifest.json
Installationstyp: Msi

[wasm-tools-net6]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 9.0.0/9.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.net6\9.0.0\WorkloadManifest.json
Installationstyp: Msi

[android]
Installationsquelle: VS 17.12.35514.174
Manifestversion: 35.0.7/9.0.100
Manifestpfad: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Installationstyp: Msi

Konfiguriert für die Verwendung loose manifests beim Installieren neuer Manifeste.

Host:
Version: 9.0.0
Architecture: x64
Commit: 9d5a6a9aa4

.NET SDKs installed:
9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.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

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Anything else?

No response

[davidfowl]

cc @eerhardt

[eerhardt]

@Steinblock, I'm not sure exactly what you would like to see changed.

.NET Aspire 8 used an inferior naming scheme. .NET Aspire 9.0 updated its Azure.Provisioning dependency from the alpha to GA version. The naming scheme changed there. The naming scheme from the alpha builds (which .NET Aspire 8.x used) wasn't correct and caused other problems. For example see Invalid Cloud deployment of Azure Service Bus topics - name truncation (dotnet/aspire#5341) and Better Azure resource name scheme (dotnet/aspire#5756).

We know this is a breaking change, which causes new/duplicate resources to be deployed. That's why we added a way to get back to the old naming scheme, so you could keep existing assets working. If you've deployed your app using 9.0 without the AspireV8ResourceNamePropertyResolver, you will have to manually delete those new/duplicated assets, since the tooling won't delete unreferenced assets.

Having a consistent naming scheme is great but since the resources get tagged with aspire-resource-name and the storage resource kept the old naming schema I think that it is intended to be handled automatically but fails for postgres and servicebus.

It was less about having a consistent naming scheme, and more about having a correct/valid naming scheme.

The tags put on the Azure resource are more for customers to use in auditing, etc. Tags aren't used in matching existing resources in new deployments. Instead the Name of the resource (in which the naming scheme changed) is what is used from deployment to deployment to match existing resources.

[Steinblock]

Because some resources use a minus and some don't after updating I guessed that the naming schema has been introduced but the resources that kept their naming schema detected the name from the existing resource and used it as a fallback.

Thanks for clarifying.