microsoft/aspire · error · DistributedApplicationException

The Rust app ' ' targets ' ', which is not compatible with…

Error message

The Rust app '{resource.Name}' targets '{target}', which is not compatible with the default musl build and runtime images. Configure both images in a single WithDockerfileBaseImage(buildImage: ..., runtimeImage: ...) call before publishing; later calls replace the previous configuration.

What it means

ResolveContainerTargetPlatform checks whether the default musl-based build and runtime images support the selected cargo target. When the target is incompatible with BOTH defaults and either a custom build image or custom runtime image is missing, the generated Dockerfile would mix incompatible images, so the publish fails with this exception instructing the developer to set both images together.

Solutions

Provide BOTH images in a single call: WithDockerfileBaseImage(buildImage: ..., runtimeImage: ...) compatible with the target.
Remove extra WithDockerfileBaseImage calls — a later call replaces the previous configuration entirely.
Switch the cargo target to one compatible with the default musl images (e.g. x86_64-unknown-linux-musl).
Verify the custom build and runtime images share the same libc (both musl or both glibc).

Example fix

// before
.WithDockerfileBaseImage(buildImage: "my/glibc-builder") // runtime image left as musl default
// after
.WithDockerfileBaseImage(buildImage: "my/glibc-builder", runtimeImage: "my/glibc-runtime");

Defensive patterns

Strategy: validation

Validate before calling

// before publishing, ensure both images are customized when the target is non-musl
if (!IsMuslCompatible(target) && (baseImages?.BuildImage is null || baseImages?.RuntimeImage is null))
    throw new InvalidOperationException("Configure both build and runtime images for non-musl targets");

Try / catch

try { PublishAsync(); }
catch (DistributedApplicationException ex) when (ex.Message.Contains("default musl build and runtime images")) {
    logger.LogError("Call WithDockerfileBaseImage once with both buildImage and runtimeImage");
}

Prevention

Always pass both buildImage and runtimeImage in a single WithDockerfileBaseImage call
Never call WithDockerfileBaseImage twice — later calls replace earlier configuration
Match libc (musl vs glibc) across build and runtime images
Verify the cargo target is musl-compatible before relying on defaults

When it happens

Trigger: Publishing a Rust app whose cargo target (e.g. a glibc/darwin target) is unsupported by the default musl images while only one of WithDockerfileBaseImage(buildImage:, runtimeImage:) fields was customized — or the second call replaced the first, leaving only one image configured.

Common situations: Calling WithDockerfileBaseImage twice (second call overwrites the first, so only one image is custom); targeting a non-musl platform like x86_64-unknown-linux-gnu or windows without providing both custom images; forgetting runtime image when a custom build image needs matching libc.

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.

Related errors

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

Appendix: source

Thrown at src/Aspire.Hosting.Rust/RustHostingExtensions.cs:905

        var targetEnvironment = targetParts[3];
        // The official Rust image index used by the default build stage publishes amd64 and arm64 images,
        // but not Docker's 32-bit arm or 386 platforms. Those architectures therefore need a custom build
        // image even when the default Alpine runtime image already supports the target platform.
        var defaultBuildImageCompatible = platform is ContainerTargetPlatform.LinuxAmd64 or ContainerTargetPlatform.LinuxArm64
            && string.Equals(targetEnvironment, "musl", StringComparison.Ordinal);
        var defaultRuntimeImageCompatible = platform == ContainerTargetPlatform.LinuxArm
            ? targetEnvironment is "musleabi" or "musleabihf"
            : string.Equals(targetEnvironment, "musl", StringComparison.Ordinal);

        var baseImages = container.Annotations.OfType<DockerfileBaseImageAnnotation>().LastOrDefault()
            ?? resource.Annotations.OfType<DockerfileBaseImageAnnotation>().LastOrDefault();
        var customBuildImageConfigured = baseImages?.BuildImage is not null;
        var customRuntimeImageConfigured = baseImages?.RuntimeImage is not null;

        if (!defaultBuildImageCompatible && !defaultRuntimeImageCompatible
            && (!customBuildImageConfigured || !customRuntimeImageConfigured))
        {
            throw new DistributedApplicationException(
                $"The Rust app '{resource.Name}' targets '{target}', which is not compatible with the default " +
                "musl build and runtime images. Configure both images in a single " +
                "WithDockerfileBaseImage(buildImage: ..., runtimeImage: ...) call before publishing; later calls replace " +
                "the previous configuration.");
        }

        if (!defaultBuildImageCompatible && !customBuildImageConfigured)
        {
            throw new DistributedApplicationException(
                $"The Rust app '{resource.Name}' targets '{target}', but the default Rust build image does not support " +
                $"container target platform '{platform}'. Configure buildImage with WithDockerfileBaseImage before publishing.");
        }

        if (!defaultRuntimeImageCompatible && !customRuntimeImageConfigured)
        {
            throw new DistributedApplicationException(
                $"The Rust app '{resource.Name}' targets '{target}', but the default Rust runtime image is not compatible " +
                "with its target ABI. Configure runtimeImage with WithDockerfileBaseImage before publishing.");

View on GitHub (pinned to 25830f84bd)