[CLI] [Regression] `aspire update` succeeds silently but leaves CPM projects broken with NU1109 package downgrade on `aspire run`
- 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
### 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
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