microsoft/aspire · error · InvalidOperationException

ASPIRERADIUS085

ASPIRERADIUS085

Error message

A password was supplied for '${resource.Name}', but the Radius recipe that provisions it deploys the workload without authentication: ${reason}. The parameter '${passwordParameter.Name}' cannot be applied, so '${resource.Name}' would be deployed unauthenticated while its consumers are handed an empty password. Remove the password to accept an unauthenticated deployment, or provision '${resource.Name}' yourself if the deployed workload must require one. Diagnostic: ASPIRERADIUS085.

What it means

A user-supplied password parameter was attached to a resource, but the Radius recipe provisions that resource without authentication, so the password cannot be applied: the workload would deploy unauthenticated while consumers are handed an empty password. This only runs in publish mode; the check relies on Default not being GenerateParameterDefault (run mode rewrites generated defaults to user-secrets wrappers).

Solutions

1. Remove the supplied password so the unauthenticated deployment is accepted knowingly.
2. Provision the resource yourself (outside the recipe) if the deployed workload must require a password.
3. Switch to a resource configuration whose recipe supports authentication.

Example fix

// before
var password = builder.AddParameter("redis-password");
var redis = builder.AddRedis("cache").WithPassword(password);
// after
var redis = builder.AddRedis("cache"); // accept recipe's unauthenticated deployment

if (passwordParameter.Default is not GenerateParameterDefault && recipeDeploysWithoutAuth) throw new InvalidOperationException($"Password for '{resource.Name}' cannot be applied: recipe deploys without authentication.");

bool IsUserSuppliedPassword(ParameterResource p) => p.Default is not GenerateParameterDefault;

try { await PublishAsync(model); } catch (InvalidOperationException ex) when (ex.Message.Contains("ASPIRERADIUS085")) { /* drop the password or provision the resource yourself */ }

When it happens

Trigger: Publishing a resource backed by a recipe that deploys without auth while the resource's password ParameterResource has an explicit/default user-supplied value (Default is not GenerateParameterDefault).

Common situations: Supplying a password via configuration/parameters for a resource type whose recipe ignores authentication; running publish with a password that only ever applied in run mode; switching resource kinds to one whose recipe does not support auth.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

• Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

• ASPIRERADIUS072
• A ConfigureRadiusInfrastructure callback changed port
• A ConfigureRadiusInfrastructure callback left container
• A ConfigureRadiusInfrastructure callback replaced port
• A ConfigureRadiusInfrastructure callback replaced the…

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

Appendix: source

Thrown at src/Aspire.Hosting.Radius/Publishing/RadiusInfrastructureBuilder.cs:2227

    /// </para>
    /// </remarks>
    private void ApplyNoCredential(
        IResource resource,
        IResourceWithConnectionString withConnectionString,
        string reason)
    {
        if (TryGetCredentialParameter(withConnectionString, "password") is not { } passwordParameter)
        {
            return;
        }

        // `Default is GenerateParameterDefault` distinguishes the two only in publish mode:
        // ParameterResourceBuilderExtensions.CreateGeneratedParameter rewrites Default to an
        // internal user-secrets wrapper in run mode. This code only ever runs while publishing —
        // the same caveat WarnIfUserSuppliedCredentialIsReplaced documents.
        if (passwordParameter.Default is not GenerateParameterDefault)
        {
            throw new InvalidOperationException(
                $"A password was supplied for '{resource.Name}', but the Radius recipe that provisions it deploys the " +
                $"workload without authentication: {reason}. The parameter '{passwordParameter.Name}' cannot be " +
                $"applied, so '{resource.Name}' would be deployed unauthenticated while its consumers are handed an " +
                $"empty password. Remove the password to accept an unauthenticated deployment, or provision " +
                $"'{resource.Name}' yourself if the deployed workload must require one. Diagnostic: ASPIRERADIUS085.");
        }

        // Registered as a substitution even though the replacement is a literal: the parameter's own
        // value is discarded everywhere it appears, so sharing it with a resource that keeps its
        // value is the same silent-mismatch hazard RegisterRecipeCredential exists to reject.
        //
        // WarnIfUserSuppliedCredentialIsReplaced is deliberately not reused here: its message says
        // the recipe generates its own credential, which is the opposite of what happens for this
        // mode. The warning below covers the generated password that reaches this point — a
        // user-supplied one has already failed the publish above — because unlike a substituted
        // credential it has no deployed counterpart.
        RegisterRecipeCredential(passwordParameter, resource, isProjectionSubstitution: true);
        _emptyCredentialSubstitutions.Add(passwordParameter);

View on GitHub (pinned to 25830f84bd)