microsoft/aspire · error · RadiusBackingResourceProjectionException

ASPIRERADIUS081

ASPIRERADIUS081

Error message

Endpoint '{endpointReference.EndpointName}' of resource '{resource.Name}' is TLS-enabled, but the Radius type '{radiusType}' that provisions it publishes no transport-security output, so '{property}' would describe how '{resource.Name}' runs locally rather than how the recipe deploys it. Remove the TLS configuration for publishing, or provision the resource yourself if the deployed workload must use TLS. Diagnostic: ASPIRERADIUS081.

What it means

When an endpoint of a resource is TLS-enabled but the resource is provisioned by a Radius recipe whose emitted backing type publishes no transport-security output, Aspire refuses to project a TLS-related endpoint property (TlsEnabled). Doing so would describe the local run mode rather than the deployed recipe behavior, producing misleading configuration in the published manifest. The failure is thrown as RadiusBackingResourceProjectionException with diagnostic ASPIRERADIUS081.

Solutions

  1. Remove the TLS configuration from the endpoint when publishing to Radius
  2. Provision the backing resource yourself (container/external resource) if the deployed workload must use TLS
  3. Check ResourceTypeMapper output for the resource type to confirm whether the recipe emits transport-security outputs

Example fix

// before
builder.AddProject<Projects.Api>("api")
    .WithEndpoint("https", e => e.TlsEnabled = true); // consumed by recipe-provisioned resource
// after
builder.AddProject<Projects.Api>("api")
    .WithEndpoint("http", e => { }); // drop TLS, or provision the backing resource yourself
Defensive patterns

Strategy: try-catch

Validate before calling

var isRecipeBacked = ResourceTypeMapper.TryGetEmittedBackingType(resource) is not null; var hasTls = endpoint.TlsEnabled; if (isRecipeBacked && hasTls) { /* remove TLS or provision yourself */ }

Try / catch

try { var expr = env.GetEndpointPropertyExpression(endpointRef, EndpointProperty.TlsEnabled); } catch (RadiusBackingResourceProjectionException ex) when (ex.Message.Contains("ASPIRERADIUS081")) { logger.LogWarning(ex, "TLS endpoint projected from recipe-backed resource"); throw; }

Prevention

When it happens

Trigger: Calling GetEndpointPropertyExpression for a TLS-enabled endpoint (e.g. EndpointProperty.TlsEnabled) where ResourceTypeMapper.TryGetEmittedBackingType returns a Radius recipe type that has no transport-security output.

Common situations: Adding WithEndpoint with TlsEnabled (or HTTPS scheme) to a resource like a database/cache that is provisioned by a Radius recipe, then consuming its endpoint properties in a dependent service.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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

Appendix: source

Thrown at src/Aspire.Hosting.Radius/RadiusEnvironmentResource.cs:255

    // recipe deploys without TLS, so it is rejected here too rather than only on the Radius path.
    private static void ThrowIfTransportSecurityIsNotRecipeBacked(EndpointReference endpointReference, EndpointProperty property)
    {
        if (!endpointReference.EndpointAnnotation.TlsEnabled ||
            property is not (EndpointProperty.Scheme or EndpointProperty.TlsEnabled or EndpointProperty.Url))
        {
            return;
        }

        // Child resources (a database on a server, say) are represented by their parent in the
        // Radius model, so classify against the resource Radius actually emits.
        var resource = endpointReference.Resource is IResourceWithParent child ? child.Parent : endpointReference.Resource;

        if (ResourceTypeMapper.TryGetEmittedBackingType(resource) is not { } radiusType)
        {
            return;
        }

        throw new RadiusBackingResourceProjectionException(
            resource,
            $"Endpoint '{endpointReference.EndpointName}' of resource '{resource.Name}' is TLS-enabled, but the Radius " +
            $"type '{radiusType}' that provisions it publishes no transport-security output, so '{property}' would " +
            $"describe how '{resource.Name}' runs locally rather than how the recipe deploys it. Remove the TLS " +
            $"configuration for publishing, or provision the resource yourself if the deployed workload must use TLS. " +
            $"Diagnostic: ASPIRERADIUS081.");
    }

    // A backing resource maps to a Radius recipe type (Applications.Datastores/*, Radius.Data/*,
    // ...) rather than Radius.Compute/containers. Its Kubernetes objects and credentials are owned
    // by the recipe, so every *address* for it is wrong. Fail loudly instead of emitting an address
    // that silently resolves to nothing.
    //
    // This guard intentionally applies to every caller that asks for an address, including
    // ComputeEnvironmentEndpointResolver, which routes here when a Kubernetes/ACA/App Service
    // consumer references a resource owned by this Radius environment. Suppressing it there would
    // not avoid a false positive — the resolver only delegates for resources this environment owns,
    // so the address really is underivable — it would merely replace an accurate failure with a

View on GitHub (pinned to 25830f84bd)