dotnet restore不遵循PackageSourceMapping与VS2022还原行为不一致问题

一、dotnet restore未遵循PackageSourceMapping的原因 #

1. NuGet版本不兼容
   Visual Studio 2022自带的NuGet客户端版本通常在6.0以上，而Package Source Mapping是NuGet 6.0才正式引入的功能。如果你的命令行dotnet对应.NET Core 2.2 SDK，它附带的NuGet版本远低于6.0，根本无法识别PackageSourceMapping配置节点，自然会忽略该规则。

2. 配置加载与缓存干扰
   即使指定了--configfile参数，全局或用户级别的NuGet.config可能存在冲突配置，或者本地缓存的旧包信息会干扰还原逻辑。可以尝试添加--no-cache参数强制刷新：

dotnet restore .\Tyndareus\Tyndareus.sln --configfile .\Tyndareus\NuGet.config --force-evaluate --no-cache

3. 配置语法错误
   检查NuGet.config中的PackageSourceMapping配置是否准确，确保源名称key与实际配置一致，通配符匹配规则正确。示例正确配置：

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

二、.NET Core 2.2对PackageSourceMapping的支持情况 #

.NET Core 2.2 SDK完全不支持PackageSourceMapping功能。该功能依赖NuGet 6.0+，而.NET Core 2.2对应的NuGet版本仅为4.8.x~5.x区间，完全无法识别相关配置节点。

这也解释了Visual Studio 2022还原正常的原因：VS 2022使用独立的高版本NuGet客户端（6.x+），能正确解析配置；而命令行dotnet restore依赖当前环境的.NET SDK版本，使用.NET Core 2.2 SDK时自然会忽略配置。

解决建议 #

• 使用高版本.NET SDK执行还原：即使项目目标框架是.NET Core 2.2，也可以安装.NET 6及以上版本的SDK，用高版本dotnet命令执行restore，就能正确识别PackageSourceMapping配置。
• 排查配置优先级：确保命令行指定的配置文件未被全局/用户级配置覆盖，必要时添加--ignore-failed-sources参数，避免从错误源拉取包。
• 验证源内包的有效性：确认Azure Devops Artifacts源中确实存在适配.NET Core 2.2的OrchardCore.ContentManagement 2.0.0包，避免因包不存在而自动 fallback 到nuget.org。

内容的提问来源于stack exchange，提问作者dahikino