[CI] Enhance NuGet package caching with SDK version-aware cache keys to prevent runtime version conflicts

[lei9444]

Summary of the Pull Request

Root Cause

PowerToys CI builds were experiencing .NET Runtime version inconsistencies where the same NuGet package versions (e.g., 9.0.7) contained different runtime build numbers (+31616 vs +31701). This occurred because Azure DevOps pipeline caching was mixing packages built with different .NET SDK versions, leading to mixed runtime versions in deps.json files

Fix

1. Added step to capture current .NET SDK version for cache key generation
2. Updated cache keys to include SDK version:
   Before: "PackageReference" | "$(Agent.OS)" | Directory.Packages.props
   After: "PackageReference" | "$(Agent.OS)" | Directory.Packages.props | $(DotNetSdkVersion)

PR Checklist

• Closes: #xxx
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[DHowett]

/cc @dfederm for msbuild caching thoughts

this seems right to me!

[dfederm]

Is this thought to be related to package caching or MSBuild caching?

I have a hard time believing it's due to package caching since that just pre-populates the NuGet cache but you're still running a restore so any missing packages will be downloaded as needed.

Can you provide details about the specific issue you're seeing? This statement specifically doesn't seem true as the package name/version aren't related to the SDK at all and are available for direct download off NuGet.org without any SDK:

where the same NuGet package versions (e.g., 9.0.7) contained different runtime build numbers

[DHowett]

@dfederm I think the problem is (perceived) to be that the .NET nuget packages aren't covered by PackageReference, our props file, or any other local asset in the project which changes when the SDK version changes.

They're governed by some file somewhere in \Program Files.

Now, the minor/revision number difference I cannot explain. I don't think the .NET team would slip up and re-release 9.0.7 (for example) with a different internal version number.

[dfederm]

This PR is changing the cache key for pre-populating the NuGet cache though (%NUGET_PACKAGES%), which:

1. Would not affect anything related to targeting/runtime packs distributed with the .NET SDK (stuff under Program Files)
2. Would, at worst, mean that the package cache isn't prepopulated "good enough" and missing packages will be downloaded from your feed instead.

I don't believe this change will help anything related to the mismatch you're seeing.

Can you provide details about the specific file(s) you're seeing a difference with and the associated pipeline(s) which produce the build outputs? We can look at the MSBuild binlogs (and/ore MSBuild cache logs) to understand where the files are originating from.

[lei9444]

Hi @dfederm @DHowett - you're right, this PR doesn't fix the issue. I'm mainly using it to test CI:#40750, I'm seeing the same issue locally as well. However, after cleaning the local NuGet cache and running a restore, the issue goes away. It seems to occur when adding a new project — specifically, there's a mismatch in the dependencies of runtimepack.Microsoft.NETCore.App.Runtime.win-x64/9.0.7, where different builds have different internal version numbers.