microsoft / microsoft/aspire

[CLI] [Regression] `aspire update` succeeds silently but leaves CPM projects broken with NU1109 package downgrade on `aspire run`

Open
#19,537 0 comments 0 reactions 0 assignees View on GitHub
area-cli
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 12h
Merged PRs (30d)
201

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

Running on a project configured with Central Package Management (CPM / ) completes successfully without warnings or errors. However, subsequent or calls fail immediately with a package downgrade error.aspire updateDirectory.Packages.propsaspire rundotnet restoreNU1109

While previous issues (#11111, #13241, and #11655) introduced CPM support in the CLI, the update workflow continues to produce broken project states when an Aspire package update brings in higher transitive dependencies (e.g., ) than what is centrally pinned in (e.g., ).Microsoft.Extensions.Hosting.Abstractions >= 10.0.11Directory.Packages.props10.0.8

Related Prior Issues
#11111 - Support Central Package Management (CPM) in aspire update command

#13241 - Aspire CLI does not properly handle CPM

#7645 - Error when using CPM

Image

### Expected Behavior

Either:

1. aspire update detects CPM and automatically bumps pinned transitive versions in to satisfy minimum version constraints of the newly upgraded Aspire components.Directory.Packages.props OR

2. aspire update runs a post-update restore check and reports actionable warnings/errors indicating which centrally pinned package versions conflict with the newly installed packages, rather than reporting a clean success.

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### Aspire doctor output

_No response_

### Anything else?

OS: Windows (x64)

.NET SDK: 10.x

Aspire CLI: Latest (target update to 13.5.0)

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the failure with a project using Directory.Packages.props: run aspire update, then aspire run or dotnet restore, and inspect the NU1109 downgrade. Trace the aspire update workflow for CPM projects and compare the centrally pinned versions with the upgraded Aspire dependencies. Done means the update either adjusts conflicting pins or reports an actionable restore failure instead of succeeding silently.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
build-system, cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.