chore(templates): unify TUnit version pinning to 1.* (#5709)

[thomhurst]

Closes #5709

Summary

• AspNet, FSharp, AspNet.FSharp, VB, Playwright templates now use 1.* wildcard, matching the basic TUnit template
• Aspire templates intentionally untouched — addressed by sibling PR for Template references stale TUnit.Aspire 1.14.0 instead of current version #5708
• Eliminates Renovate maintenance PRs for these templates

Test plan

• All affected templates parse and resolve
• No Directory.Build.props swap regression

[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]

Code Review

Summary

This PR aligns five template project files (AspNet, AspNet.FSharp, FSharp, Playwright, VB) from a pinned 1.39.0 version to the floating 1.* range, matching the strategy already used in the canonical TUnit/TestProject.csproj. The goal is to eliminate Renovate churn from repeated version-bump PRs.

---

What's Done Well

• Clean, minimal diff. 7 additions, 7 deletions, no collateral changes.
• Correct scope. Only TUnit-family packages are floated; third-party packages (Microsoft.AspNetCore.Mvc.Testing, etc.) remain pinned, which is the right call — those have independent release cadences.
• Consistent with the existing canonical template. The basic TUnit/TestProject.csproj has used 1.* all along; this PR makes the rest match.
• TUnit.Assertions.FSharp also updated. Both F# templates correctly update both TUnit and TUnit.Assertions.FSharp together since they're versioned in lockstep.
• Aspire templates are intentionally left out and delegated to sibling PR #5742 — the right split since TUnit.Aspire has its own release cadence.

---

Notes / Minor Points

Major-version breakage behaviour: When TUnit 2.0 ships, 1.* will silently stop getting updates rather than breaking anything — users would be stuck on the latest 1.x at the time of their dotnet restore. This is standard NuGet floating-range behaviour and is acceptable for a template users are expected to modify. Worth noting somewhere (docs or a comment) that users upgrading to TUnit 2.0 will need to manually update the version range.

1.* vs. [1,2) explicitness: The issue raised both options. 1.* is a NuGet shorthand for "highest available 1.x.x", functionally equivalent to [1.0.0, 2.0.0). Staying with 1.* over [1,2) is fine since it's consistent with what the canonical template already uses.

Renovate config: No changes to renovate.json are needed — with 1.* in place, Renovate treats the range as already-floating and will not produce version-bump PRs.

Pre-existing indentation inconsistency: TUnit.VB/TestProject.vbproj and TUnit.AspNet.FSharp use tabs while TUnit.AspNet uses spaces for <PackageReference> lines. Not introduced by this PR and not blocking.

---

Verdict

Correct, low-risk, self-contained cleanup that closes a real maintenance pain point. No functional changes to generated template content, no test or snapshot changes required.

Recommend: Approve and merge, preferably together with #5742 so the full template surface is consistent.

Optional: consider documenting the 1.* convention as the intentional policy for TUnit-family packages in templates (e.g., a comment in Directory.Build.props or in a template README), so future contributors don't accidentally re-pin these.

[claude]

Follow-up Review

Previous suggestion addressed: The optional feedback from my earlier review — documenting the 1.* convention as an explicit policy — was addressed in commit e1521b5bac40 with a well-written comment block in Directory.Build.props.

What the new commit adds

The comment in Directory.Build.props is clear and hits all the right points:

• Scope: names exactly which package families this applies to (TUnit, TUnit.Aspire, TUnit.Playwright, TUnit.Assertions.FSharp)
• Rationale: explains why (Renovate churn, always-fresh scaffolded projects)
• Guard rail: explicitly says "Do NOT re-pin" — this is the key line that prevents future contributors from undoing the change
• Third-party carve-out: correctly calls out that non-TUnit packages keep exact versions

Assessment

This is a solid, complete change. The policy is now:

1. Enforced in the project files (the 1.* references)
2. Documented at the right level (Directory.Build.props, which governs all template content)
3. Scoped correctly (Aspire excluded pending sibling PR)

No open concerns from the previous review remain. Ready to merge alongside or after #5742.