Detect and surface Azure credential provider selection for local provisioning

[Copilot]

Description

Azure local provisioning previously required users to manually configure credential sources without detecting what's available or providing guidance. This adds automatic detection of Azure CLI, Visual Studio, VS Code, Azure PowerShell, and Azure Developer CLI credentials, presenting only available options to users during provisioning setup.

Implementation

• CredentialProviderDetector: Detects available credential providers by attempting token acquisition

  • Uses Azure.Identity TokenCredential classes directly (AzureCliCredential, VisualStudioCredential, etc.)
  • Attempts GetTokenAsync with 5-second timeout for each provider
  • Returns list of working credentials without executing external commands or checking PATH
  • Always includes Interactive Browser as fallback

• Provisioning Context Providers: Added credential selection prompt before tenant/subscription selection

  • RunMode: Shows dropdown with detected providers when CredentialSource is unset
  • PublishMode: Includes activity reporting during detection with fallback to manual entry
  • Both modes use injected logger and pass tenant ID to detector
  • Tenant input depends on credential source - automatically cascades when credential changes
  • Subscription input depends on tenant - automatically cascades when tenant changes

• DefaultTokenCredentialProvider: Enhanced to track credential source changes

  • Recreates credential when either TenantId or CredentialSource changes
  • Added VisualStudioCode credential case to switch statement
  • Removed DefaultAzureCredential fallback - now uses AzureCli as default for both run and publish modes
  • Throws InvalidOperationException for unsupported credential sources
  • Ensures fresh credentials are used when fetching tenants and subscriptions after credential changes

• Localization: Added strings for credential provider names, selection dialogs, and first-time user guidance

User Experience

When no credential providers are detected:

To use Azure local provisioning, you need to be logged in with one of the following:
- Azure CLI: Run `az login`
- Visual Studio: Sign in through Tools → Options → Azure Service Authentication
- Visual Studio Code: Install Azure Account extension and sign in
- Azure PowerShell: Run `Connect-AzAccount`
- Azure Developer CLI: Run `azd auth login`

Selected credential source is persisted to configuration (Azure:CredentialSource) and not prompted again. When CredentialSource is not configured or set to "Default", AzureCli is used as the default credential provider.

When users change their credential provider, the tenant and subscription dropdowns automatically refresh with the appropriate options for the new credential, creating a seamless cascading experience.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
  • No
• Does the change require an update in our Aspire docs?
  • Yes
  • No

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Improve Azure local provisioning: detect and facilitate first time login, show credential choices</issue_title>
<issue_description>Is your feature request related to a problem? Please describe the problem.

Today, Aspire assumes that the user is already logged into Visual Studio, VS Code, or Azure CLI for Azure local provisioning. The current experience does not detect which of these mechanisms (if any) are available, nor does it facilitate login or provide a UI for the user to choose their preferred credential provider. There is a configuration option for selecting a credential provider, but this is not surfaced in the user experience.

Describe the solution you'd like

1. Detect available credential providers in the user's environment (VS, VS Code, az cli, etc) and present the user with a choice of which to use for login.
2. If no login mechanism is detected, proactively facilitate or guide the user through the login process for one of the supported providers.
3. Surface the credential provider configuration option in a user-friendly way.

Additional context
Improving this experience will make the first-time Azure login in Aspire smoother and more intuitive, especially for new users.

cc @eerhardt
</issue_description>

<agent_instructions>Update the ProvisioningContextProviders:

• PublishModeProvisioningContextProvider.cs
• RunModeProvisioningContextProvider

Add a credential input that lets people pick the credential source. Detect the existing sources, and show them in
an options list.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Improve Azure local provisioning: detect and facilitate first time login, show credential choices #10364

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[davidfowl]

Simplify this logic and just use the TokenCredential and don't check for stuff on the PATH or by running commands. Just delegate.

[Copilot]

Simplified credential detection to use TokenCredential directly. Now creates credential instances and attempts GetTokenAsync with a 5-second timeout instead of checking PATH or running commands. Fixed in 2f9b506.

[davidfowl]

Don't do this for the logger. There's one injected.

[Copilot]

Fixed to use the injected logger. Changed CredentialProviderDetector to accept non-generic ILogger so both providers can pass their loggers directly. Fixed in 2f9b506.

[davidfowl]

@copilot Implement the PR feedback, make sure the DefaultTokenCredentialProvider does appropriately update

[Copilot]

@copilot Implement the PR feedback, make sure the DefaultTokenCredentialProvider does appropriately update

Implemented all feedback in 2f9b506:

• Simplified credential detection to use TokenCredential classes directly
• Fixed logger injection to use the injected logger
• Updated DefaultTokenCredentialProvider to track CredentialSource changes and recreate credential when it changes
• Added missing VisualStudioCode case to the credential switch statement

[davidfowl]

@copilot We never want to use DefaultAzureCredential anymore

[Copilot]

@copilot We never want to use DefaultAzureCredential anymore

Removed DefaultAzureCredential fallback. Now uses AzureCli as the default for both run and publish modes when CredentialSource is null or "Default". Throws InvalidOperationException for unsupported credential sources. Fixed in b585517.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13538

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13538"

[davidfowl]

@copilot When the credential changes, it should also cause the tenants and subscriptions to change. It should cascade.

[Copilot]

@copilot When the credential changes, it should also cause the tenants and subscriptions to change. It should cascade.

Added cascade behavior in f0776bb. In RunMode, tenant input now depends on CredentialSource and updates the credential before fetching tenants. In PublishMode, sequential prompts ensure credential is set before fetching tenants. DefaultTokenCredentialProvider already tracks CredentialSource changes and recreates the credential automatically, so tenants and subscriptions will use the new credential when fetched.