microsoft/aspire · error · DistributedApplicationException

Java application ' ' cannot be published because its…

Error message

Java application '{resource.Name}' cannot be published because its working directory was changed to '{resource.WorkingDirectory}' after the container build context was set to '{appDirectory}'. Pass the directory to AddJavaApp instead of calling WithWorkingDirectory afterwards.

What it means

AddJavaApp captures the working directory as the Docker build context at creation time. Calling WithWorkingDirectory afterwards changes where the app runs without changing the build context, so the published image would be built from stale sources. Aspire detects the mismatch at publish time and throws, telling you to pass the directory to AddJavaApp instead.

Solutions

  1. Remove the WithWorkingDirectory call and pass the intended directory directly to AddJavaApp.
  2. If run directory and build context must genuinely differ, restructure so AddJavaApp's appDirectory is the directory you want for both.
  3. Keep a single source of truth for the app directory in the AddJavaApp call.

Example fix

// before
var api = builder.AddJavaApp("api", "src/Api");
api.WithWorkingDirectory("src/Api/bin");
// after
var api = builder.AddJavaApp("api", "src/Api");
Defensive patterns

Strategy: validation

Validate before calling

var appDir = "src/Api";
var runDir = "src/Api"; // intended working directory
if (!string.Equals(Path.GetFullPath(appDir), Path.GetFullPath(runDir), StringComparison.OrdinalIgnoreCase))
    throw new Exception("Pass the working directory to AddJavaApp, not WithWorkingDirectory");

Try / catch

try { /* publish */ }
catch (DistributedApplicationException ex) when (ex.Message.Contains("WithWorkingDirectory afterwards"))
{ /* move the directory into AddJavaApp and remove the later call */ }

Prevention

When it happens

Trigger: Calling builder.AddJavaApp(name, appDirectory) and later resource.WithWorkingDirectory(otherDir) where otherDir differs from appDirectory, then publishing.

Common situations: Refactoring run behavior to a different output directory; copying patterns from other resource types where WithWorkingDirectory is common; assuming WithWorkingDirectory also moves the build context.

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/9a3282f8260a84ab. Report an issue: GitHub.

Appendix: source

Thrown at src/Aspire.Hosting.Java/JavaHostingExtensions.cs:135

                if (File.Exists(Path.Combine(appDirectory, "Dockerfile")))
                {
                    resource.Annotations.Add(new JavaAuthoredDockerfileAnnotation());
                    return;
                }

                containerBuilder.WithDockerfileBuilder(
                    appDirectory,
                    ctx =>
                    {
                        // The build context was fixed when PublishAsDockerFile ran, which is during
                        // AddJavaApp, and DockerfileBuildAnnotation.ContextPath cannot be changed
                        // afterwards. A later WithWorkingDirectory therefore moves where the application
                        // runs without moving what is uploaded to the daemon, and the image would be built
                        // from the original directory. Saying so is far better than producing an image
                        // whose sources come from somewhere the author no longer points at.
                        if (!ArePathsEquivalent(resource.WorkingDirectory, appDirectory))
                        {
                            throw new DistributedApplicationException(
                                $"Java application '{resource.Name}' cannot be published because its working " +
                                $"directory was changed to '{resource.WorkingDirectory}' after the container " +
                                $"build context was set to '{appDirectory}'. Pass the directory to " +
                                "AddJavaApp instead of calling WithWorkingDirectory afterwards.");
                        }

                        JavaDockerfileGenerator.Write(resource, appDirectory, ctx);
                    });
            });

        // The generated image copies files out of each container files source, so those sources have to be
        // built first. PublishAsDockerFile removes the Java resource from the model, but the container it
        // substitutes shares this annotation collection, so the callback still runs; the step lookup matches
        // on resource name and therefore finds the substituted container's build steps.
        resourceBuilder.WithPipelineConfiguration(context =>
        {
            if (resource.TryGetAnnotationsOfType<ContainerFilesDestinationAnnotation>(out var containerFilesAnnotations))
            {

View on GitHub (pinned to 25830f84bd)