aspire update --channel hides restore errors and rolls back changes, making dependency conflicts hard to diagnose #22214

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

aspire update --channel staging fails when the updated AppHost has a dependency conflict, but reports only a generic restore failure. The underlying NuGet/MSBuild output is neither displayed nor captured in the CLI log. Channel-update validation then rolls back the candidate edits, so the user cannot simply run dotnet restore on the updated project to see what went wrong.

This made an eShop update from Aspire 13.6 to 17.0 look like a channel/NuGet.config problem when the reported underlying failure was actually a centrally pinned dependency downgrade.

The same discussion reported that a stable update leaves the edits in place despite a restore failure. Although the dependency conflict still needs fixing, that behavior at least lets the user rerun restore and diagnose it.

Expected Behavior

An ordinary update should let the user apply the requested upgrade and work through remaining dependency conflicts rather than requiring a successful validation restore before preserving the changes. Validation-only behavior should be explicit (for example, --dry-run).

Whenever restore/validation fails, show the actual NuGet/MSBuild diagnostics, capture them in the CLI log, and clearly state whether the update was applied or rolled back. Do not leave the user with only a generic failure and no way to inspect the candidate graph.

This report concerns update behavior and diagnosability; the dependency conflict itself is not evidence of an incorrect staging feed and does not imply that the CLI should blindly override user-owned central package pins.

Steps To Reproduce

Reported by participants in the Teams discussion on November 12, 2026; not independently reproduced as part of filing this issue.

1. Clone the public dotnet/eShop repository in its reported state: Aspire references at 13.6.0 (some at 13.6.0-preview.1.26479.8) and centrally pinned Microsoft.Extensions packages at 10.0.12.

2. Run:

   git clone https://github.com/dotnet/eShop
   cd eShop
   aspire update --channel staging

3. The CLI proposes updates including Aspire.AppHost.Sdk and Aspire.Hosting.Dotnet to 17.0.0, and Aspire.Hosting.Foundry to 17.0.0-preview.1.26562.1.

4. Observe the generic restore error, with no underlying NuGet diagnostics. The channel-update edits are rolled back, preventing a subsequent restore from exposing the candidate dependency conflict.

The exact eShop commit and installed CLI version were not provided, so future eShop changes may remove this particular reproduction.

Exceptions (if any)

User-visible failure:

Failed to restore packages for project D:\git\eShop\src\eShop.AppHost\eShop.AppHost.csproj after update.

Underlying restore error reported after investigation:

NU1109: Detected package downgrade:
Microsoft.Extensions.Configuration.Abstractions
from 10.0.15 to centrally defined 10.0.12.
eShop.AppHost -> Aspire.Hosting.Dotnet 17.0.0
-> Microsoft.Extensions.Configuration.Abstractions (>= 10.0.15)

Aspire doctor output

Not supplied.

Anything else?

• Original report used Windows (D:\git\eShop). Exact SDK, CLI, and tooling versions were not supplied.
• Related work already in progress: #22207: Separate channel update validation with aspire update --dry-run and #22208: Surface restore output when update validation fails.

Created from a Teams conversation with Jose Perez Rodriguez (@joperezr).