Azure DevOps NuGet还原失败 无法加载源服务索引问题咨询

你碰到的URL中源名称被替换为GUID的问题，是Azure DevOps Server 2019 版本.Net Core还原任务的已知适配bug：该版本任务在读取下拉选择的本地Artifacts内部源时，会错误读取源的内部GUID标识拼接路径，而非读取源的访问名称拼接正确URL，直接导致还原请求打到不存在的地址报NU1301错误。
旧版蓝色NuGet任务因为发布更早，对本地部署Artifacts源的路径解析逻辑在2019版本中已经稳定，所以相同配置下.Net Framework项目可以正常还原。

最快的修复方式是绕开任务的源选择下拉逻辑，手动指定源配置：

• 在解决方案根目录新建nuget.config文件，提交到代码仓库，配置内容参考：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="NuGetPackages" value="http://<你的ADO服务器地址>/_packaging/NuGetPackages/nuget/v3/index.json" />
  </packageSources>
</configuration>

• 编辑流水线中的.Net Core还原任务，将包源选择模式改为从NuGet.config读取源，选中你刚提交的配置文件，开启构建账号对内部源的访问权限即可。
• 如果你的构建代理是首次访问HTTP协议的内部源，提前在代理机器执行dotnet nuget trust http://<你的ADO服务器地址>添加信任，避免触发HTTP源拦截报错。

1. 旧版NuGet任务和.Net Core还原任务的核心差异 #

• 旧版蓝色NuGet任务：底层调用Windows平台专属的NuGet.exe命令行，默认绑定和Visual Studio/MSBuild匹配的NuGet客户端版本，针对传统.Net Framework项目做适配，在Azure DevOps Server 2019版本中对本地Artifacts源的身份认证、路径解析逻辑已经经过多版本验证，稳定性更高。
• 黑色.Net Core还原任务：底层调用跨平台的dotnet restore命令，使用.Net SDK内置的NuGet组件，针对.Net Core/.NET 5+ 项目设计，不依赖Windows专属组件，但在Azure DevOps Server 2019发布时，对本地部署场景的Artifacts源适配存在遗漏，才会出现你碰到的路径解析bug。

2. .Net6项目是否可以使用旧版NuGet还原任务 #

完全可以，只要满足两个前提，且不会影响现有.Net Framework 4.x项目的正常生成：

• 将旧版NuGet任务使用的NuGet.exe版本升级到5.9及以上（推荐6.x稳定版），不同版本的NuGet.exe在代理机器上是并行存放的，旧项目配置的低版本NuGet.exe不会被覆盖。
• 如果你碰到MSBuild v17找不到的提示，不需要修改全局环境配置，只需要在旧版NuGet任务的高级设置中，手动指定构建代理上安装的VS2022（或Build Tools 2022）对应的MSBuild 17路径，或者将MSBuild查找规则改为「优先查找最新版本」即可。
• 注意：如果你的构建流水线需要在Linux/macOS代理上运行，就不能用旧版NuGet任务，只能用.Net Core还原任务配合自定义nuget.config的方案。

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