Summary
AddAzureSqlServer(...).AddDatabase(...) referenced by a compute resource emits an api-roles-<sql> deployment script that grants the app's managed identity access to the database. On Azure the script fails before it reaches SQL, which fails the entire azd provision.
Error
DeploymentScriptError: System.MissingMethodException: Method not found:
'Void Microsoft.Extensions.Caching.Memory.MemoryCache..ctor(
Microsoft.Extensions.Options.IOptions`1<Microsoft.Extensions.Caching.Memory.MemoryCacheOptions>)'.
at Microsoft.SqlServer.Management.AlwaysEncrypted.Management.SqlAKVProviderWithDisposableCache..ctor(TokenCredential tokenCredential)
at Microsoft.SqlServer.Management.AlwaysEncrypted.Management.AlwaysEncryptedManagement.SetCustomProvidersWithDisposableCache(Boolean useGlobalCredential)
at Microsoft.SqlServer.Management.PowerShell.Shared.AzureKeyVaultUtilities.RegisterCustomKeyStoreProviders(String keyVaultAccessToken, String managedHsmAccessToken, SqlConnection conn)
at Microsoft.SqlServer.Management.PowerShell.GetScriptCommand.ProcessRecord()
It retries 5 times (the script's own retry loop) over ~5 minutes and then throws, so provisioning fails with:
deployment failed: step "provision" failed: deploying layer provision: error deploying infrastructure
Cause
The generated script pins the SqlServer module and runs it on Az PowerShell 14.0:
# Install SqlServer module - using specific version to avoid breaking changes in 22.4.5.1 (see #9926)
Install-Module -Name SqlServer -RequiredVersion 22.3.0 -Force -AllowClobber -Scope CurrentUser
Import-Module SqlServer
...
Invoke-Sqlcmd -ConnectionString $connectionString -Query $sqlCmd
with azPowerShellVersion: '14.0'. SqlServer 22.3.0 binds an older Microsoft.Extensions.Caching.Memory than the one Az 14.0 ships, so Invoke-Sqlcmd throws on load while initialising the Always Encrypted / AKV providers.
The pin to 22.3.0 was itself a workaround for #9926, so this looks like the pin has aged out relative to the Az PowerShell image.
Reproduction
- AppHost with
AddAzureAppServiceEnvironment, a project resource, and AddAzureSqlServer("control-sql").AddDatabase("Catalog") with api.WithReference(database).
azd up into a fresh subscription/resource group.- Provisioning creates the server and database, then fails on the
api-roles-<sql> deployment script.
Reproduced identically on 13.3.5 and 13.4.6 — the two versions emit the same script (azPowerShellVersion: '14.0', RequiredVersion 22.3.0), so this is not a recent regression.
Impact
There is no opt-out. WithRoleAssignments exists only for Container Registry and Storage, and the roles module is emitted whenever an Azure SQL resource and a compute resource share the model — it is still generated after removing WithReference(database). The only workarounds are to materialise the infrastructure with azd infra generate and delete the module, or to drop Azure SQL from the AppHost model entirely (which also removes the app's managed identity, so it is not viable on its own).
Suggested fixes
- Pin a SqlServer module version compatible with the Az PowerShell image, or pin
azPowerShellVersion to one compatible with SqlServer 22.3.0.
- Consider
Invoke-Sqlcmd -DisableVariables/a lighter path, or Microsoft.Data.SqlClient directly, to avoid the Always Encrypted provider registration that triggers the load.
- Provide an opt-out (e.g.
WithRoleAssignments for Azure SQL) so users can manage the contained user themselves.
Environment
- Aspire 13.4.6 (also 13.3.5), azd 1.25.0, .NET 10.0.300
- Azure App Service Linux + Azure SQL serverless
GP_S_Gen5, region Belgium Central
Summary
AddAzureSqlServer(...).AddDatabase(...)referenced by a compute resource emits anapi-roles-<sql>deployment script that grants the app's managed identity access to the database. On Azure the script fails before it reaches SQL, which fails the entireazd provision.Error
It retries 5 times (the script's own retry loop) over ~5 minutes and then throws, so provisioning fails with:
Cause
The generated script pins the SqlServer module and runs it on Az PowerShell 14.0:
with
azPowerShellVersion: '14.0'. SqlServer 22.3.0 binds an olderMicrosoft.Extensions.Caching.Memorythan the one Az 14.0 ships, soInvoke-Sqlcmdthrows on load while initialising the Always Encrypted / AKV providers.The pin to 22.3.0 was itself a workaround for #9926, so this looks like the pin has aged out relative to the Az PowerShell image.
Reproduction
AddAzureAppServiceEnvironment, a project resource, andAddAzureSqlServer("control-sql").AddDatabase("Catalog")withapi.WithReference(database).azd upinto a fresh subscription/resource group.api-roles-<sql>deployment script.Reproduced identically on 13.3.5 and 13.4.6 — the two versions emit the same script (
azPowerShellVersion: '14.0',RequiredVersion 22.3.0), so this is not a recent regression.Impact
There is no opt-out.
WithRoleAssignmentsexists only for Container Registry and Storage, and the roles module is emitted whenever an Azure SQL resource and a compute resource share the model — it is still generated after removingWithReference(database). The only workarounds are to materialise the infrastructure withazd infra generateand delete the module, or to drop Azure SQL from the AppHost model entirely (which also removes the app's managed identity, so it is not viable on its own).Suggested fixes
azPowerShellVersionto one compatible with SqlServer 22.3.0.Invoke-Sqlcmd -DisableVariables/a lighter path, orMicrosoft.Data.SqlClientdirectly, to avoid the Always Encrypted provider registration that triggers the load.WithRoleAssignmentsfor Azure SQL) so users can manage the contained user themselves.Environment
GP_S_Gen5, region Belgium Central