diff --git a/src/frontend/src/content/docs/integrations/cloud/azure/overview.mdx b/src/frontend/src/content/docs/integrations/cloud/azure/overview.mdx index 0238cb9bf..e09490ffa 100644 --- a/src/frontend/src/content/docs/integrations/cloud/azure/overview.mdx +++ b/src/frontend/src/content/docs/integrations/cloud/azure/overview.mdx @@ -68,6 +68,8 @@ To have your Azure resources use the local emulators, chain a call the `RunAsEmu Calling any of the available `RunAsEmulator` APIs on an Azure resource builder doesn't affect the [publishing manifest](/architecture/resource-publishing/). When you publish your app, [the generated Bicep file](/integrations/cloud/azure/customize-resources/) reflects the actual Azure service, not the local emulator. +When you run an AppHost, Aspire adds an `azure-environment` resource to represent the Azure provisioning environment. If every Azure resource in the app model is configured with `RunAsEmulator` (so none require provisioning), Aspire hides the `azure-environment` resource from the dashboard, since it has no provisioning work to represent. Adding any Azure resource that requires provisioning—one that isn't running as an emulator—makes the `azure-environment` resource visible again. + ### Local containers Some Azure resources can be substituted locally using open-source or on-premises containers. To substitute an Azure resource locally in a container, chain a call to the `RunAsContainer` method on the Azure resource builder. This method configures the Azure resource to use a containerized version of the service for local development and testing, rather than the actual Azure service. 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..e04cf34b5 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 @@ -214,10 +214,12 @@ The managed server keeps its logging defaults, while application settings can ov - **Consistent file upload limits.** The Interaction Service now enforces one file for single-file prompts and 100 files for multi-file prompts across dashboard, CLI, and custom clients. Server-generated temporary names and deterministic cleanup protect uploaded content. - **Resolved debug environments.** Extension authors can opt into the new experimental `WithDebugSupport` overload that receives `LaunchConfigurationCallbackContext`, including the resource's resolved environment variables. Existing mode-based overloads keep their signatures; recompile and confirm binding because the synchronous overload now has `OverloadResolutionPriority(-1)`. - **More reliable local orchestration.** DCP startup gets a readiness-aware timeout on contended hosts, terminal hosts clean up orphaned sockets, and proxied executable target ports use Aspire's non-ephemeral range to avoid bind races. +- **Cleaner emulator-only dashboards.** When every Azure resource in the app model runs as a local emulator, Aspire hides the `azure-environment` resource from the dashboard instead of showing it stuck in **Not started**. Adding any Azure resource that requires provisioning keeps `azure-environment` visible. - See [Interaction Service file uploads](/extensibility/interaction-service/) - and the [`ASPIREEXTENSION001` diagnostic](/diagnostics/aspireextension001/). + See [Interaction Service file uploads](/extensibility/interaction-service/), + the [`ASPIREEXTENSION001` diagnostic](/diagnostics/aspireextension001/), and + [local emulators](/integrations/cloud/azure/overview/#local-emulators). ## 🛠️ Aspire CLI enhancements