From 10c122864e7f5ae134b33e50f1888480ea580ab0 Mon Sep 17 00:00:00 2001 From: "aspire-repo-bot[bot]" <268009190+aspire-repo-bot[bot]@users.noreply.github.com> Date: Thu, 10 Sep 2026 18:15:07 +0000 Subject: [PATCH 1/2] Document Azure Front Door origin naming change (#20035) Azure Front Door origins now derive their name from the backend hostname in addition to the resource group ID, so switching backends creates a new origin instead of reusing the previous origin's Azure identity. This is a breaking deployment change. - Update the Azure Front Door integration doc with the new generated origin name, a breaking-change caution, and a ConfigureInfrastructure override to preserve pre-13.6 origin names. - Add a breaking-change entry to What's new in Aspire 13.6, plus a mention in the Integration updates section. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../cloud/azure/azure-front-door.mdx | 42 ++++++++++++++++++- .../content/docs/whats-new/aspire-13-6.mdx | 37 +++++++++++++++- 2 files changed, 77 insertions(+), 2 deletions(-) diff --git a/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx b/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx index c25e0d447..de352985a 100644 --- a/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx +++ b/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx @@ -156,6 +156,20 @@ When you publish your app, Aspire generates Bicep alongside the manifest. A Fron **Upgrading from Aspire 13.3.0-preview:** The resource names generated for Front Door profiles, endpoints, origin groups, origins, and routes changed in Aspire 13.4. This can result in duplicate Azure resources (profiles, endpoints, origin groups, routes, and origins) during an upgrade. To avoid duplicates, either remove the existing Azure resources before redeploying, or set resource names explicitly using `ConfigureInfrastructure`. + + ```bicep title="Generated Bicep — frontdoor.bicep" @description('The location for the resource(s) to be deployed.') param location string = resourceGroup().location @@ -196,7 +210,7 @@ resource my_apiOriginGroup 'Microsoft.Cdn/profiles/originGroups@2025-06-01' = { } resource my_apiOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2025-06-01' = { - name: take('myapiOrigin-${uniqueString(resourceGroup().id)}', 90) + name: take('myapiOrigin-${uniqueString(resourceGroup().id, my_api_host)}', 90) properties: { hostName: my_api_host originHostHeader: my_api_host @@ -288,6 +302,32 @@ await builder.build().run(); For more information, see [Customize Azure resources](/integrations/cloud/azure/customize-resources/). For the full list of configurable properties, see the [Azure.Provisioning.Cdn](https://learn.microsoft.com/dotnet/api/azure.provisioning.cdn) and [Azure.Provisioning.FrontDoor](https://learn.microsoft.com/dotnet/api/azure.provisioning.frontdoor) API documentation. +#### Preserve origin names from before Aspire 13.6 + +Starting in Aspire 13.6, generated origin names include the origin's backend hostname alongside the resource group ID, so switching an origin's backend produces a new origin name. To keep the origin names Aspire generated before 13.6, override them with `ConfigureInfrastructure` before the first deployment after upgrading: + +```csharp title="AppHost.cs" +using Azure.Provisioning; +using Azure.Provisioning.Cdn; +using Azure.Provisioning.Expressions; + +builder.AddAzureFrontDoor("frontdoor") + .WithOrigin(api) + .ConfigureInfrastructure(infrastructure => + { + foreach (var origin in infrastructure.GetProvisionableResources() + .OfType()) + { + // Match the previous default: remove underscores and hash only the resource-group ID. + origin.Name = BicepFunction.Take( + BicepFunction.Interpolate($"{origin.BicepIdentifier.Replace("_", "")}-{BicepFunction.GetUniqueString(BicepFunction.GetResourceGroup().Id)}"), + origin.GetResourceNameRequirements().MaxLength); + } + }); +``` + +This callback runs after the integration's defaults and applies to every configured origin. Opting out this way means the deployed origin's Azure identity no longer changes when its backend hostname changes, so you're responsible for cleaning up any origins left behind by incremental deployments while both naming schemes were in use. + ## See also - [Azure Front Door documentation](https://learn.microsoft.com/azure/frontdoor/) diff --git a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx index 716d4292e..4e5ff107a 100644 --- a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx +++ b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx @@ -34,7 +34,7 @@ This release introduces: - **Integration improvements** — debug Blazor WebAssembly apps, discover Dev Tunnel URLs, customize Radius recipes, and protect destructive Azure location changes. - **Updated emulator images** — move Azure App Configuration to `1.2.0` and make the Linux-based vNext Cosmos DB emulator the default. - **Community contributions** — 13 pull requests from eight contributors span major features, integration improvements, reliability fixes, and project tooling. -- **One breaking change** — `RunAsEmulator` now selects the Linux-based vNext Cosmos DB emulator. +- **Two breaking changes** — `RunAsEmulator` now selects the Linux-based vNext Cosmos DB emulator, and Azure Front Door origin names now include the backend hostname. - …and much more. ## 🆙 Upgrade to Aspire 13.6 @@ -298,6 +298,7 @@ Existing integrations add new workflows and safer defaults: - **Azure identity reliability.** Role-assignment Bicep detects service principal and federated workload identity credentials more accurately, and the experimental Sandboxes integration now binds its deployment principal to the scoped data-owner role correctly. - **Cosmos DB client health.** `AddAzureCosmosClient` and `AddKeyedAzureCosmosClient` register default-on health checks that probe account reachability. Set `DisableHealthChecks` to opt out. - **Foundry model refreshes.** Generated Foundry model constants were refreshed throughout the release cycle without changing the hosting API shape. +- **Front Door origin identity.** Generated origin names now include the origin's backend hostname, so switching backends creates a distinct origin instead of reusing the previous origin's Azure identity. Review the [breaking-change guidance](#breaking-changes) before upgrading. ```bicep title="Generated Bicep — frontdoor.bicep" @@ -302,32 +292,6 @@ await builder.build().run(); For more information, see [Customize Azure resources](/integrations/cloud/azure/customize-resources/). For the full list of configurable properties, see the [Azure.Provisioning.Cdn](https://learn.microsoft.com/dotnet/api/azure.provisioning.cdn) and [Azure.Provisioning.FrontDoor](https://learn.microsoft.com/dotnet/api/azure.provisioning.frontdoor) API documentation. -#### Preserve origin names from before Aspire 13.6 - -Starting in Aspire 13.6, generated origin names include the origin's backend hostname alongside the resource group ID, so switching an origin's backend produces a new origin name. To keep the origin names Aspire generated before 13.6, override them with `ConfigureInfrastructure` before the first deployment after upgrading: - -```csharp title="AppHost.cs" -using Azure.Provisioning; -using Azure.Provisioning.Cdn; -using Azure.Provisioning.Expressions; - -builder.AddAzureFrontDoor("frontdoor") - .WithOrigin(api) - .ConfigureInfrastructure(infrastructure => - { - foreach (var origin in infrastructure.GetProvisionableResources() - .OfType()) - { - // Match the previous default: remove underscores and hash only the resource-group ID. - origin.Name = BicepFunction.Take( - BicepFunction.Interpolate($"{origin.BicepIdentifier.Replace("_", "")}-{BicepFunction.GetUniqueString(BicepFunction.GetResourceGroup().Id)}"), - origin.GetResourceNameRequirements().MaxLength); - } - }); -``` - -This callback runs after the integration's defaults and applies to every configured origin. Opting out this way means the deployed origin's Azure identity no longer changes when its backend hostname changes, so you're responsible for cleaning up any origins left behind by incremental deployments while both naming schemes were in use. - ## See also - [Azure Front Door documentation](https://learn.microsoft.com/azure/frontdoor/) diff --git a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx index 4e5ff107a..212ad6629 100644 --- a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx +++ b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx @@ -391,9 +391,17 @@ If you adopt the new default: ### Front Door origin names now include the backend hostname -Azure Front Door origin names generated by the Aspire hosting integration now combine the resource group ID with the origin's backend hostname, instead of hashing the resource group ID alone. This is a breaking deployment change, even though the integration is still in preview: upgrading changes origin resource names even when the backend hostname hasn't changed. [Incremental ARM deployments](https://learn.microsoft.com/azure/azure-resource-manager/templates/deployment-modes#incremental-mode) don't remove resources omitted from the new template, so existing origins can remain alongside the newly named origins in the same origin group. Endpoint, origin-group, and route names are unchanged. +Azure Front Door origin names generated by the Aspire hosting integration now combine the resource group ID with the origin's backend hostname, instead of hashing the resource group ID alone. This is a breaking deployment change: upgrading to Aspire 13.6 changes the generated origin resource names, even when the backend hostname hasn't changed. Endpoint, origin-group, and route names are unchanged. -To preserve the previous default origin names, override them with `ConfigureInfrastructure` before the first deployment after upgrading: +[Incremental ARM deployments](https://learn.microsoft.com/azure/azure-resource-manager/templates/deployment-modes#incremental-mode) don't remove resources omitted from the new template, so existing origins can remain alongside the newly named origins in the same origin group. + +**Recommended approach:** Adopt the new naming policy, which gives an origin a new identity when its backend hostname changes: + +1. Deploy your app with Aspire 13.6 using the new default origin names. +2. Confirm that the newly named origins are healthy and serve the intended backends. +3. Manually delete the old origins from each affected origin group. + +**Fallback:** If the recommended deployment and cleanup approach isn't feasible, preserve the previous default origin names by overriding them with `ConfigureInfrastructure` before the first deployment after upgrading: ```csharp title="AppHost.cs" using Azure.Provisioning;