NuGet.Config precedence: project‑level vs solution‑level packageSources

Answer

When both a solution‑level .nuget\NuGet.Config and a project‑level NuGet.Config define a packageSources entry with the same key, the project‑level value completely replaces the solution‑level value. The lists are not concatenated; only the later file’s entry for that key is kept.

Confirmed facts

• NuGet processes configuration files in this order: machine‑wide → user‑wide → solution‑level → project‑level.
• For the packageSources section, later files override earlier entries that share the same key.
• If the keys differ, both sources appear in the restored list, which can look like a merge in logs.
• There is no dedicated switch to ignore solution‑level sources; adding a <clear/> element before re‑adding desired sources in the project file achieves that effect.

Steps to verify the behavior

1. Create a solution folder.
2. Add .nuget\NuGet.Config with a source, e.g.:

   <configuration>
     <packageSources>
       <add key="SolutionSrc" value="https://solution.example" />
     </packageSources>
   </configuration>

3. Add a project‑level NuGet.Config next to the project file. For the same key:

   <configuration>
     <packageSources>
       <add key="SolutionSrc" value="https://project.example" />
     </packageSources>
   </configuration>

   For a different key, just add another <add> element.
4. Run dotnet restore -v detailed (or msbuild -t:Restore) and examine the log for lines like "Adding package 'SolutionSrc' with value ...".
5. If you want to suppress the solution source entirely, place <clear/> before the project’s <add> element.

Missing diagnostic detail

Confirm the version of the dotnet CLI/NuGet you are using (e.g., dotnet --version). The override rule described applies to NuGet 3.x and later; older NuGet.exe versions may exhibit different merging behavior.