Enterprise hardening: repo nuget.config breaks corporate packageSourceMapping setups

[ChrisonSimtian]

Summary

The repo's nuget.config does <clear/> and registers nuget.org under the source name nuget. Any developer whose user-level %APPDATA%\NuGet\NuGet.Config (or platform equivalent) contains a <packageSourceMapping> block keyed to a different source name — e.g. the very common nuget.org — gets a fully broken restore with cryptic NU1100 errors and downstream NU1109 "package downgrade" phantoms.

This blocks any contributor on a corporate NuGet setup and is exactly the kind of paper-cut that erodes credibility for the enterprise-CI/CD positioning we want.

Repro

User-level NuGet.Config contains (common corporate pattern):

<packageSourceMapping>
  <packageSource key=\"nuget.org\">
    <package pattern=\"*\" />
  </packageSource>
  <packageSource key=\"CorpFeed\">
    <package pattern=\"Corp.*\" />
  </packageSource>
</packageSourceMapping>

Then dotnet restore nuke-common.slnx fails with errors like:

error NU1100: Unable to resolve 'NuGet.Packaging (>= 6.14.3)' for 'net10.0'.
PackageSourceMapping is enabled, the following source(s) were not considered:
C:\Program Files\dotnet\library-packs, nuget.

(nuget here is the repo's source key — the user-level mapping is for nuget.org, which no longer exists in the resolved source list.)

Root cause

Source-name mismatch. NuGet source mapping is keyed by source name, not URL. When the repo overrides the source list with the name nuget, every user-level mapping rule keyed to nuget.org becomes effectively dead.

Suggested fix

Two options, both small:

1. Rename the source to nuget.org in nuget.config — aligns with the de-facto standard name, transparently works with the majority of corporate user configs that follow it.
2. Add an explicit <packageSourceMapping> block in the repo's nuget.config that maps * to the repo's source. This wins regardless of user config because the repo-level mapping fully overrides:

<packageSourceMapping>
  <packageSource key=\"nuget.org\">
    <package pattern=\"*\" />
  </packageSource>
</packageSourceMapping>

Recommend doing both (rename + add explicit mapping) for belt-and-braces.

Verification

Confirmed locally: restoring with a clean --configfile pointing to a minimal nuget.org-only config succeeds (26/26 projects). The downstream NU1109 errors I initially saw on pr/1592-vulnerable-transitives were phantoms from the broken restore, not real version conflicts.

Why this belongs in 10.2.0

Part of the enterprise-grade CI/CD positioning. Any corporate contributor or CI agent with a packageSourceMapping block hits this. It's a 3-line config change.