ci: use setup-dotnet built-in NuGet cache

[thomhurst]

Summary

• Drop the dedicated actions/cache step for NuGet packages in .github/workflows/dotnet.yml in favour of actions/setup-dotnet's built-in cache.
• Key the cache on Directory.Packages.props only — with Central Package Management enabled, it's the sole source of package versions, so hashing csproj files adds nothing.

Trade-off

setup-dotnet's cache does not expose restore-keys, so a version bump now triggers a full cache miss instead of a partial restore. Simpler config in exchange for occasional full re-downloads.

Test plan

• CI run on this PR restores/saves the cache via setup-dotnet
• Subsequent run with no Directory.Packages.props change reports a cache hit

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[claude]

Code Review

Clean simplification overall. The change is straightforward and the PR description is refreshingly honest about the trade-offs.

What's good

• Removing the hand-rolled actions/cache step in favour of setup-dotnet's built-in cache reduces moving parts and maintenance burden.
• Keying only on Directory.Packages.props is sound reasoning for a Central Package Management repo — package versions are fully centralised there, so hashing every *.csproj was redundant (and added key churn whenever any project file changed, even for non-package changes).

Potential concerns

1. Loss of continue-on-error

The removed step had continue-on-error: true, which meant a transient cache-service outage would silently fall through to a full restore without breaking the build. The setup-dotnet cache doesn't expose that option. If GitHub's cache service is temporarily unavailable the step could fail and block CI. In practice setup-dotnet probably handles this gracefully internally, but it's worth verifying against its source or confirming from a CI run that shows a cache miss scenario (not just a hit).

2. Relative path vs. glob for cache-dependency-path

The original key used **/Directory.Packages.props — a glob that would pick up any nested props files. The new cache-dependency-path: Directory.Packages.props is a relative path rooted at the repo root. If the project ever gains a sub-directory with its own Directory.Packages.props (e.g. a samples or docs sub-repo), those changes won't bust the cache. Low risk right now, but something to keep in mind.

3. Edge case: new package reference without a version bump

If a PackageReference is added to a *.csproj for a package whose version is already declared in Directory.Packages.props (e.g. a second project starts using a package the first already used), the cache key won't change but the restored cache will be stale until the next full miss. This is genuinely rare with CPM and the overhead is just one extra restore, so it's not a blocker — just good to document in a follow-up comment or ADR if the team cares about cache correctness guarantees.

Summary

The acknowledged restore-keys trade-off is acceptable — partial restores are nice-to-have, not critical. The change is a net improvement in simplicity. The continue-on-error point is the only one worth a quick sanity-check before merging; if the CI run on this PR completes cleanly (including a forced-miss scenario) it can be considered confirmed.