Skip to content

chore(deps): update aspire#6165

Merged
thomhurst merged 1 commit into
mainfrom
renovate/aspire
Jun 5, 2026
Merged

chore(deps): update aspire#6165
thomhurst merged 1 commit into
mainfrom
renovate/aspire

Conversation

@thomhurst
Copy link
Copy Markdown
Owner

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Type Update Change
Aspire.AppHost.Sdk msbuild-sdk patch 13.4.013.4.2
Aspire.Hosting.AppHost nuget patch 13.4.013.4.2
Aspire.Hosting.PostgreSQL nuget patch 13.4.013.4.2
Aspire.Hosting.RabbitMQ nuget patch 13.4.013.4.2
Aspire.Hosting.Redis nuget patch 13.4.013.4.2
Aspire.Hosting.Testing nuget patch 13.4.013.4.2
Aspire.Npgsql.EntityFrameworkCore.PostgreSQL nuget patch 13.4.013.4.2
Aspire.StackExchange.Redis nuget patch 13.4.013.4.2
Aspire.StackExchange.Redis.OutputCaching nuget patch 13.4.013.4.2
TUnit.Aspire nuget minor 1.*1.5*

Release Notes

microsoft/aspire (Aspire.AppHost.Sdk)

v13.4.2: Aspire 13.4.2

What's New in Aspire 13.4.2

Patch release for Aspire 13.4 with a fix for Redis persistent container deadlock on startup when using TLS.

🐛 Fixes
  • 🔴 Redis with WithLifetime(ContainerLifetime.Persistent) could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #​17822. (#​17827, backported via #​17850, @danegsta)
🏷️ Housekeeping

Full Changelog: microsoft/aspire@v13.4.1...v13.4.2

Full commit: d7d0b6759ce4b936c76bc4775814d27db560dd6d

Generated by Generate release notes for a new stable Aspire release · ● 5M

v13.4.1: Aspire 13.4.1

What's New in Aspire 13.4.1

Patch release for Aspire 13.4 with fixes for explicit-start resource lifecycle callbacks, Redis persistent container startup, proxyless endpoint allocation, and a duplicated profiles block in the empty C# AppHost template.

🐛 Fixes
  • ⏱️ Explicit-start resources triggered lifecycle callbacks too early — Session-scoped resources marked with WithExplicitStart() were having their execution configuration callbacks (environment variables, arguments, certificates) evaluated at AppHost startup instead of at manual start. This meant user-interaction callbacks such as WithEnvironment(ctx => PromptForValueAsync(...)) were called before the user triggered the resource. DCP registration is now deferred until the user manually starts the resource; persistent explicit-start resources still register immediately but patch the existing DCP record to Start = true rather than deleting and recreating it. Fixes #​17813. (#​17825, backported via #​17826, @danegsta)
  • 🔴 Redis with WithLifetime(ContainerLifetime.Persistent) could deadlock on startup — Redis TLS startup arguments used the public/allocated host ports instead of the internal target ports. When the public port differed from the target port (or was not yet allocated) the container would listen on an unexpected port and become unreachable. The TLS and non-TLS startup arguments now bind to target ports, matching what Redis expects internally. Fixes #​17822. (#​17827, backported via #​17850, @danegsta)
  • 🔌 Proxyless container endpoint could hang when resolved before container creation — Referencing a proxyless container endpoint in an environment variable callback (before the container port spec was finalized) could deadlock. An on-demand allocation path now commits the target port as the fallback host port in that case; once BuildContainerPorts runs, normal DCP dynamic port assignment takes over for any later resolution. (#​17851, backported via #​17859, @danegsta)
  • 📄 Empty C# AppHost template emitted duplicate profiles blockaspire new aspire-empty on 13.4 produced an aspire.config.json with a profiles block that duplicated the content already present in apphost.run.json, causing redundant launch configuration. The embedded template now contains only the required appHost.path binding; profile configuration lives exclusively in apphost.run.json. Fixes #​17660. (#​17781, backported via #​17820, @mitchdenny)
🏷️ Housekeeping
  • 📦 Added Aspire CLI npm package to the release pipeline so the npm distribution is published as part of stable releases. (#​17297, backported via #​17766, @adamint)
  • 🚀 Bumped branding to 13.4.1 (#​17819)

Full Changelog: microsoft/aspire@v13.4.0...v13.4.1

Full commit: cf985fa817dd5863e7f62eb74fa1725ab5069ed2

Generated by Generate release notes for a new stable Aspire release · ● 1.0.40

Generated by Generate release notes for a new stable Aspire release · ● 3.9M

thomhurst/TUnit (TUnit.Aspire)

v1.50.0: 1.50.0

What's Changed
Other Changes

Full Changelog: v1.49.0...v1.50.0

v1.49.0: 1.49.0

What's Changed
Other Changes
Dependencies

Full Changelog: v1.48.6...v1.49.0

v1.48.6: 1.48.6

What's Changed
Other Changes
Dependencies

Full Changelog: v1.48.0...v1.48.6

v1.48.0: 1.48.0

What's Changed
Other Changes
Dependencies

Full Changelog: v1.47.0...v1.48.0

v1.47.0: 1.47.0

What's Changed
Other Changes

@thomhurst thomhurst added dependencies Pull requests that update a dependency file MINOR PATCH renovate-bot labels Jun 5, 2026
@thomhurst thomhurst enabled auto-merge (squash) June 5, 2026 21:08
@codacy-production
Copy link
Copy Markdown

codacy-production Bot commented Jun 5, 2026

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric Results
Complexity 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

Copy link
Copy Markdown
Contributor

@claude claude Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Overall: Clean, well-scoped dependency update — no blocking issues.

Summary

This PR updates 9 Aspire packages from 13.4.0 → 13.4.2 (patch) and tightens the TUnit.Aspire version constraint in templates. The critical fix here is the Redis TLS persistent container deadlock: Aspire was using public/allocated host ports instead of internal target ports for TLS startup args, causing Redis to become unreachable when ports differed.


Strengths

  • Consistent updates: All 9 Aspire packages bumped uniformly across Directory.Packages.props, AppHost SDK references, template projects, and the CloudShop example — no version drift.
  • Correct use of central package management: The two centrally-managed packages (Aspire.Hosting.AppHost, Aspire.Hosting.Testing) flow through Directory.Packages.props as expected; template/example projects with explicit pins are intentionally standalone.
  • Low risk: Patch-level update; backward-compatible by semantic versioning contract.

Observation: TUnit.Aspire version constraint narrowing (1.*1.5*)

In both template files (TUnit.Aspire.Starter and TUnit.Aspire.Test), the floating constraint changes from any 1.x release to only 1.5.x releases.

This is reasonable — templates scaffold starter code for new users, and pinning to the current minor line (1.5*) prevents new projects from silently picking up a 1.6+ release that could have breaking changes before Renovate can open a PR to update the constraint.

Worth confirming: Is this constraint updated by the same Renovate configuration that opened this PR? If so, the workflow is self-maintaining and nothing more is needed. If not, it would be worth checking that the constraint will be bumped to 1.6* when 1.6 is released, so templates don't stagnate.


Minor: CloudShop example packages not centrally managed

Packages like Aspire.Hosting.Redis, Aspire.Hosting.PostgreSQL, Aspire.StackExchange.Redis, etc. in the CloudShop and template .csproj files carry explicit version pins and are not in Directory.Packages.props. This is fine — these projects are standalone examples, not part of the main build graph — but it does mean version updates to these packages require touching multiple files individually (as this PR does). A future consideration might be to unify into a shared Directory.Packages.props for the examples folder, but that's out of scope here.


Verdict: Approve. The patch bump is correct and the Redis TLS deadlock fix is a meaningful reliability improvement.

Copy link
Copy Markdown
Contributor

@claude claude Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review (follow-up pass)

A detailed review was already posted above. This pass confirms there is nothing additional to flag.

Summary of what this PR does: Bumps 9 Aspire packages from 13.4.013.4.2 (patch) and narrows the TUnit.Aspire floating constraint in templates from 1.* to 1.5*. The key fix in Aspire 13.4.2 is a Redis persistent-container deadlock on TLS startup caused by using the public host port instead of the internal target port.

Checklist:

  • All affected files updated consistently — no stragglers left at 13.4.0.
  • Template projects (TUnit.Aspire.Starter, TUnit.Aspire.Test) and CloudShop example both updated.
  • Directory.Packages.props centrally-managed packages updated correctly.
  • No TUnit engine, source-generator, or test metadata changes — purely a dependency version bump.
  • Auto-merge (squash) is already enabled, which is appropriate for a bot-managed Renovate PR.

No blocking issues. This is a safe, well-scoped patch update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file MINOR PATCH renovate-bot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants