Problem

When dotnet publish fails during container image building in aspire publish, users see confusing "unexpected error" messages instead of clear, actionable error information. This happens because the ExecuteDotnetPublishAsync method in ResourceContainerImageBuilder is missing the ThrowOnNonZeroReturnCode = false setting in its ProcessSpec configuration.

Root Cause

The issue stems from inconsistent ProcessSpec configuration between different build paths:

Docker/Podman builds (working correctly):

var spec = new ProcessSpec("docker") {
    // ...
    ThrowOnNonZeroReturnCode = false,  // ✅ Explicitly set
    // ...
};

dotnet publish builds (problematic):

var spec = new ProcessSpec("dotnet") {
    // ...
    // ❌ Missing ThrowOnNonZeroReturnCode = false
    // ...
};

When ThrowOnNonZeroReturnCode is not explicitly set to false, ProcessUtil.Run() throws an exception on command failure instead of allowing graceful error handling through exit code checking.

Solution

This PR adds ThrowOnNonZeroReturnCode = false to the ProcessSpec in ExecuteDotnetPublishAsync to match the behavior of Docker/Podman builds. This allows:

1. Graceful error handling - Failed builds return false instead of throwing exceptions
2. Proper step completion - Publishing steps complete with error state rather than bubbling exceptions
3. Consistent behavior - All container build paths handle errors the same way
4. Better user experience - Clear error messages instead of "unexpected error"

Changes

• ResourceContainerImageBuilder.cs: Added ThrowOnNonZeroReturnCode = false to ProcessSpec in ExecuteDotnetPublishAsync method
• ResourceContainerImageBuilderTests.cs: Added test BuildImageAsync_WithInvalidProject_ReturnsFalseWithoutThrowing to validate the fix

Validation

The fix has been validated to ensure consistency across all container runtime implementations:

• ✅ Docker runtime: 5 ProcessSpec instances with ThrowOnNonZeroReturnCode = false
• ✅ Podman runtime: 2 ProcessSpec instances with ThrowOnNonZeroReturnCode = false
• ✅ ResourceContainerImageBuilder: Now has 1 ProcessSpec instance with ThrowOnNonZeroReturnCode = false

This minimal change ensures that failed dotnet publish commands during container builds are handled gracefully with proper error reporting, matching the established patterns used throughout the codebase.

This pull request was created as a result of the following prompt from Copilot chat.

Fix confusing error messages when Docker image builds fail during aspire publish

Problem

When dotnet publish fails during container image building in aspire publish, users see confusing "unexpected error" messages instead of clear, actionable error information. This happens because the ExecuteDotnetPublishAsync method in ResourceContainerImageBuilder is missing the ThrowOnNonZeroReturnCode = false setting in its ProcessSpec configuration.

Root Cause

The issue stems from inconsistent ProcessSpec configuration between different build paths:

Docker/Podman builds (working correctly):

var spec = new ProcessSpec("docker") {
    // ...
    ThrowOnNonZeroReturnCode = false,  // ✅ Explicitly set
    // ...
};

dotnet publish builds (problematic):

var spec = new ProcessSpec("dotnet") {
    // ...
    // ❌ Missing ThrowOnNonZeroReturnCode = false
    // ...
};

When ThrowOnNonZeroReturnCode is not explicitly set to false, ProcessUtil.Run() throws an exception on command failure instead of allowing graceful error handling through exit code checking.

Solution

Add ThrowOnNonZeroReturnCode = false to the ProcessSpec in ExecuteDotnetPublishAsync to match the behavior of Docker/Podman builds. This allows:

1. Graceful error handling - Failed builds return false instead of throwing exceptions
2. Proper step completion - Publishing steps complete with error state rather than bubbling exceptions
3. Consistent behavior - All container build paths handle errors the same way
4. Better user experience - Clear error messages instead of "unexpected error"

Changes

• Fix ProcessSpec configuration in ResourceContainerImageBuilder.ExecuteDotnetPublishAsync
• Add test to validate the fix works correctly
• Ensure error handling consistency across all container build paths

Testing

The fix includes a test that validates:

• Failed dotnet publish commands don't throw exceptions
• Error information is properly captured and logged
• Publishing pipeline completes gracefully with error state

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.