microsoft/aspire · error · InvalidOperationException

Changing the location of Azure resource

Error message

Changing the location of Azure resource '{0}' requires deleting and recreating it. Any data in the deleted resource may be permanently lost. Set the '{1}' command argument to true to continue.

What it means

Thrown when a change-location operation on an Azure resource would require deleting and recreating the resource, but the user has not explicitly confirmed the destructive action. Because command confirmations are UI metadata not enforced for non-interactive CLI/MCP callers, the controller requires an explicit ConfirmDelete command argument set to true before proceeding.

Solutions

Pass the ConfirmDelete command argument as true (e.g. --ConfirmDelete true) on the change-location command after acknowledging data loss.
Back up/export any data in the resource before confirming, since deletion may permanently destroy it.
If data preservation is impossible (e.g. location-bound data), plan recreation and re-provisioning of dependent resources.
For interactive flows, complete the dashboard/CLI confirmation prompt instead of bypassing it.

Example fix

// before
aspire publish --operation change-location --resource mydb --location westus
// after
aspire publish --operation change-location --resource mydb --location westus --ConfirmDelete true

Defensive patterns

Strategy: validation

Validate before calling

// supply the confirmation argument when the location actually changes
var args = currentLocation != targetLocation
    ? new Dictionary<string, object?> { ["ConfirmDelete"] = true }
    : new Dictionary<string, object?>();

Try / catch

try { await controller.ChangeLocationAsync(resource, newLocation, args); }
catch (InvalidOperationException ex) when (ex.Message.Contains("requires deleting and recreating"))
{
    // surface a confirmation prompt; re-invoke with ConfirmDelete=true on acceptance
}

Prevention

Never rely on dashboard confirmation metadata for CLI/MCP automation — pass the explicit argument.
Back up resource data before any location change.
Detect location changes up front and ask the user for confirmation in your tooling.
Remember location changes are destructive recreations, not moves.

When it happens

Trigger: Invoking the change-resource-location command where the target's current location differs from the effective location and the ConfirmDeleteArgumentName command argument is absent or not true (confirmDelete == false).

Common situations: Moving a resource to another Azure region via CLI/MCP automation without passing the confirmation argument; relying on the dashboard confirmation checkbox that non-interactive callers bypass; forgetting the argument after a script refactor.

Understand the failure class

Background: "--flag is required" and "must specify" CLI errors: how missing-required-flag validation works and how to fix it — this error's family across 20 libraries.

Related errors

AI-assisted analysis of microsoft/aspire@25830f84bd (2026-09-16). Data as JSON: /api/errors/1a32db86f176782e. Report an issue: GitHub.

Appendix: source

Thrown at src/Aspire.Hosting.Azure/AzureProvisioningController.cs:3458

            return null;
        }

        var armClientProvider = serviceProvider.GetRequiredService<IArmClientProvider>();
        var tokenCredentialProvider = serviceProvider.GetRequiredService<ITokenCredentialProvider>();
        var armClient = armClientProvider.GetArmClient(tokenCredentialProvider.TokenCredential, context.SubscriptionId);
        if (!await armClient.ResourceExistsAsync(resourceId, cancellationToken).ConfigureAwait(false))
        {
            // Cached state can point at a resource that has already been manually deleted. In that
            // case the location change only needs to update local override state and reprovision.
            return null;
        }

        if (!confirmDelete)
        {
            // Resource command confirmations are UI metadata and are not enforced by non-interactive
            // CLI or MCP callers. Require an explicit command argument before publishing transient
            // state or reaching the destructive boundary.
            throw new InvalidOperationException(FormatUserString(
                AzureProvisioningStrings.ChangeResourceLocationDeleteConfirmationRequiredFormat,
                resource.Name,
                ConfirmDeleteArgumentName));
        }

        return new(armClient, resourceId, currentLocation);
    }

    private async Task DeleteCachedResourceForLocationChangeAsync(
        AzureBicepResource resource,
        string requestedLocation,
        LocationChangeResourceDeletion? resourceDeletion,
        CancellationToken cancellationToken)
    {
        if (resourceDeletion is null)
        {
            return;
        }

View on GitHub (pinned to 25830f84bd)