Document Azure resource naming breaking change

[eerhardt]

In https://github.com/dotnet/aspire/pull/5809, and as part of the move to the new Azure.Provisioning versions, we are making a change to how Azure resources are named.

See https://github.com/dotnet/aspire/issues/5756 for the description of the problem / reasoning for the change.

To revert back to using the .NET Aspire v8 naming scheme, the following code can be added to the beginning of the AppHost's Program.cs:

using Aspire.Hosting.Azure;

var builder = DistributedApplication.CreateBuilder(args);
builder.Services.Configure<AzureProvisioningOptions>(options =>
{
    // insert the v8 naming resolver at the front of the list so it is used to provide resource names
    options.ProvisioningContext.PropertyResolvers.Insert(0, new AspireV8ResourceNamePropertyResolver());
});

@IEvangelist - We could also take this opportunity to document how to use the ProvisioningContext to customize the Azure resources created in an Aspire app. Do you want a separate issue tracking that? or is it OK to reuse this issue? It would be great if we had a base set of documentation from the Azure SDK we could point to. cc @tg-msft

[IEvangelist]

Sounds good, thanks for adding this @eerhardt. I'm curious though, why not have the version be a parameter on the resolver?

using Aspire.Hosting.Azure;

var builder = DistributedApplication.CreateBuilder(args);
builder.Services.Configure<AzureProvisioningOptions>(options =>
{
    // insert the v8 naming resolver at the front of the list so it is used to provide resource names
    options.ProvisioningContext.PropertyResolvers.Insert(
        0,
        new AspireResourceNamePropertyResolver(ResourceNameVersion.V8));
});

Or something like that? AspireV8ResourceNamePropertyResolver just feels so specific. This is for release 9.0, correct?

[eerhardt]

This is for release 9.0, correct?

correct

why not have the version be a parameter on the resolver?

I don't plan on this being a "long lived" class. It was created just to make reverting the breaking change back to help people move to the new version. I don't plan on us having "V9", "V10", etc. versions.

Going forward we are going to use the default Azure.Provisioning behavior. And if there are breaking changes in the naming scheme there, Azure.Provisioning will need to provide the backwards compatibility.