fix(templates): floating TUnit.Aspire version (#5708)

[thomhurst]

Closes #5708

Summary

• Aspire templates now use 1.* for TUnit.Aspire (matched to basic TUnit template strategy)
• Directory.Build.props local-project swap still resolves correctly during in-repo builds
• End-user installs from NuGet templates now scaffold with current TUnit.Aspire instead of stale 1.14.0

Test plan

• Restore succeeds for affected csproj files
• Local ProjectReference swap unaffected

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

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.}

[claude]

Review: fix(templates): floating TUnit.Aspire version

The fix correctly addresses the staleness problem described in #5708. The two-line change is minimal, targeted, and the Directory.Build.props local-project-swap mechanism continues to work correctly for in-repo builds since it removes the PackageReference entirely before the floating version is ever evaluated.

What's good

• The root cause is well-understood: Directory.Build.props swaps TUnit.Aspire for a local ProjectReference during solution builds, so the hardcoded version is never exercised in-repo. End users scaffolding from NuGet get the raw .csproj without that Directory.Build.props, so 1.* will now resolve to the latest published 1.x release instead of the stale 1.14.0.
• The 1.* strategy is already used consistently for the base TUnit package in content/TUnit/TestProject.csproj, so this change harmonizes the Aspire templates with that existing convention.
• Both Aspire template variants (TUnit.Aspire.Test and TUnit.Aspire.Starter) are updated together, avoiding a split where one template would still scaffold stale.

One concern: incomplete fix for other TUnit templates

The floating-version treatment is only applied to TUnit.Aspire. Looking at the rest of the template tree, several other TUnit packages still use hardcoded patch versions:

File	Package	Version
TUnit.Playwright/TestProject.csproj	TUnit.Playwright	1.39.0
TUnit.AspNet/TestProject/TestProject.csproj	TUnit	1.39.0
TUnit.FSharp/TestProject.fsproj	TUnit	1.39.0
TUnit.FSharp/TestProject.fsproj	TUnit.Assertions.FSharp	1.39.0
TUnit.AspNet.FSharp/TestProject/TestProject.fsproj	TUnit	1.39.0
TUnit.AspNet.FSharp/TestProject/TestProject.fsproj	TUnit.Assertions.FSharp	1.39.0
TUnit.VB/TestProject.vbproj	TUnit	1.39.0

These are subject to exactly the same staleness problem: there is no equivalent Directory.Build.props swap for them, so end users scaffolding these templates will get whichever patch version was current at the time the template was last published. They would benefit from 1.* for the same reasons as TUnit.Aspire.

The scope of this PR is focused on the Aspire regression that prompted issue #5708, so landing it as-is is reasonable. But it would be worth opening a follow-up to extend the floating-version strategy to TUnit.Playwright, TUnit.AspNet, TUnit.FSharp, TUnit.AspNet.FSharp, and TUnit.VB templates, or alternatively configuring Renovate to track all of these files so bumps are automated.

Minor note: 1.* vs [1,2) vs >=1.0.0

1.* is NuGet's floating-patch shorthand and resolves to the highest available 1.x.y at restore time. This is consistent with the base TUnit template and is appropriate here. A [1,2) range would express the same intent more explicitly in SemVer terms, but 1.* is idiomatic in the .NET template ecosystem and there's no reason to change it.

Summary

The fix is correct and safe. The only suggested follow-up is broadening the same strategy to the remaining TUnit template packages that still pin exact patch versions.