Switch to MS proxy feed for nuget - #6498

The config change itself looks correct and self-contained: src/nuget.config is the only NuGet source config in the repo, nothing else references nuget.org as a source key, and there's no packageSourceMapping to keep in sync. I also confirmed the new service index answers anonymously (HTTP 200, valid v3 index, no credentials), so external contributors and forks shouldn't be blocked.

One thing worth flagging so the green checks aren't over-read: CI doesn't actually exercise this change. All four NuGetCommand@2 tasks and the DotNetCoreCLI@2 restore in azure-pipelines.yml omit feedsToUse/nugetConfigPath, so they fall back to feedsToUse: select + includeNuGetOrg: true. The build log for this PR shows the task synthesizing its own config and restoring from nuget.org regardless:

nuget.exe sources Add -Name NuGetOrg -Source https://api.nuget.org/v3/index.json -ConfigFile ...\tempNuGet_387935.config
Installed Microsoft.Windows.CppWinRT 3.0.260520.1 from https://api.nuget.org/v3/index.json

So src/nuget.config only affects local/VS builds today, and a future availability or coverage problem on the proxy would surface as a broken dev box rather than a red pipeline. Would it be worth a follow-up setting feedsToUse: config + nugetConfigPath: src/nuget.config on those tasks so the proxy is on the validated path?

Related question: is anonymous external consumption of packagefeedproxy.microsoft.io a supported contract for package versions not already cached in the backing feed (e.g. after a future dependency bump), or only for what's already there?

Approving - the diff is right, these are follow-ups rather than blockers.

Re-approving — the new commit addresses my earlier feedback. I verified the updated restore configuration against build 387990's logs.

The repository config is now exercised by CI. Previously the restore tasks defaulted to feedsToUse: select, so the pipeline generated its own config and selected nuget.org independently of src/nuget.config. With feedsToUse: config + nugetConfigPath on all five restore tasks:

[command]...nuget.exe restore ...\AppInstallerCLI.sln ... -ConfigFile D:\a\1\s\src\nuget.config
Feeds used:
  https://packagefeedproxy.microsoft.io/nuget/v3/index.json

No log in that build references api.nuget.org, and the emitted Feeds used: sections identify the proxy as the remote source. Packages resolved through it verify their signatures successfully.

The temporary config path in DotNet Restore is expected task behavior — DotNetCoreCLI@2 copies the supplied NuGet.config into a temp config for task-managed auth — and its restore output likewise resolves from the proxy.

The x64_release failure is not feed-related. Restore succeeded on that leg; the failure is disk exhaustion during compile/link:

Error C1083: Cannot open compiler intermediate file: 'x64\Release\AppInstallerCLITests.ipdb': Not enough space
LINK: Error LNK1257: code generation failed