Dotnet Build(CLI)无法恢复.NET Framework4.8 NuGet包，求解决办法

以下是针对你遇到的场景（VS可正常构建但命令行/自动化脚本失败，无法升级框架）的可行解决办法：

• 检查NuGet源配置差异
  命令行环境和Visual Studio使用的NuGet源可能不一致，执行dotnet nuget list source查看当前命令行的源配置，对比Visual Studio中「工具→NuGet包管理器→程序包源」的设置。如果有缺失的必要源，用dotnet nuget add source <源地址> -n <源名称>添加。若涉及私有源，需确保命令行配置了正确凭据：dotnet nuget update source <源名称> -u <用户名> -p <密码>。

• 指定具体项目/解决方案路径执行命令
  避免在错误的工作目录执行命令，明确指定要操作的.csproj或.sln文件：

  dotnet restore MyProject.csproj
  dotnet build MySolution.sln
  

• 清理本地NuGet缓存
  本地缓存损坏可能导致恢复失败，执行以下命令清空所有NuGet缓存：

  dotnet nuget locals all --clear
  

  完成后重新执行dotnet restore。

• 适配packages.config格式的项目
  若你的项目使用的是旧版packages.config而非PackageReference，dotnet cli对其支持有限。可以尝试：

  1. 在Visual Studio中右键packages.config文件，选择「迁移到PackageReference」（确认兼容当前框架后操作）；
  2. 若无法迁移，使用NuGet CLI执行恢复：nuget restore MyProject.csproj（需先安装NuGet CLI工具）。

• 强制绑定Restore与Build步骤
  执行命令时显式指定先执行Restore再Build，确保恢复步骤被强制执行：

  dotnet build /t:Restore;Build MyProject.csproj
  # 或使用msbuild命令
  msbuild /t:Restore /t:Build MyProject.csproj
  

• 检查NuGet.config文件冲突
  项目根目录、用户目录（%appdata%\NuGet\NuGet.config）或系统目录的NuGet.config可能存在配置冲突（如禁用了必要源、设置了错误代理）。可临时移走项目根目录的NuGet.config，使用默认配置测试是否恢复正常。

内容的提问来源于stack exchange，提问作者André Viana