当前位置：文江博客话题详情

azure-devops azure-pipelines nuget-package-restore

Azure Devops Nuget Restore失败了，“无法为源代码加载服务索引。

发布于 2025-02-11 20:19:36 字数 1047 浏览 3 评论 0 原文

我们有一个内部Azure Devops 2019服务器，目前我正在为新的.NET6解决方案设置构建，该解决方案的项目从Nuget.org引用了各种软件包和我们ADO服务器的“工件”区域中的内部feed。

在此为.NET6的情况下，我假设我必须使用“ .NET Core”还原任务（Black Square图标），而不是较旧的“ Nuget”还原任务（蓝色图标）？因此，我添加了前者，并配置了如下所示的相关设置，其中“ nugetpackages”是我们内部提要的名称：

当我运行构建时，此任务将随着该任务而失败信息

错误nu1301：无法加载源的服务索引http：//ghy/_packaging/2df3c440-07a5-4c01-4c01-8e5c-bfbd6e132f09/nuget/nuget/v3/index.json.json.json.json.json.json.

我们内部提要的URL是： http：//ghyder_package/nugetpackages/nuget/v3/index.json ，那么为什么URL中的提要名被用错误消息中看到的GUID代替？大概这就是还原失败的原因。

顺便说一句，我们有许多.NET框架4.x解决方案，这些解决方案可以引用相同的软件包并构建良好。这些使用旧的“ nuget”（蓝色图标）还原任务，但是设置与上图中的设置相同，这表明较新的“ .NET Core”任务正在做一些奇怪的事情。

（顺便说一句，有人可以解释“ Nuget”任务与“ .NET Core”任务之间的区别？我还能在.net6构建管道中使用旧任务吗？我早些时候尝试了一下，但它抱怨MSBUILD V17没有安装，也不想继续走这条路，因为担心破坏4.x版本）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

甜嗑 2025-02-18 20:19:36

在这里尚未提及的东西，但是在尝试从另一个项目中恢复饲料时，我的痛苦是我的痛苦的根源，但是同一组织是消费项目的某些设置...（sic。

在将管道权限添加到nuget feed之后 /en-us/azure/devops/trafacts/feeds/feed-permissions？view = azure-devops＃pipelines-permissions“ rel =“ noreferrer”> https://learlen.microsoft.com/en-microsoft.com/en-us/azure/devops /工件/feeds/feed-permissions？view = azure-devops＃pipelines-permissions ），您需要更新限制正在恢复项目中正在恢复的项目的工作授权范围... 提要。

回复收藏 0 原文

瑾夏年华 2025-02-18 20:19:36

我刚刚花了将近两天的时间来打击同样的NU1301错误，而我的ADO实例是基于云的，而“最新”，即与您的情况不完全相似，但也许我的经历会带来一些灯光。

tldr;是否有ADO“项目”构建服务帐户访问“组织”工件供稿的许可问题。 DotnetCorecli@2还原任务的输出甚至没有暗示朝着这个方向暗示，但是当我丢下back使用Nuget Restore任务时，错误消息更具信息性，并帮助我发现了基本问题。

此信息并未阐明您提出的GUID/NAME交换问题，但也许GUID是一个内部ID，首先用于解决该名称，并且如果权限问题甚至阻止了对trifacts endpoint的查询

...对于MSBUILD V17评论，我会非常仔细地注意此建议和您对现有构建的烦恼。用旧的嘲讽来解释……这并不是真正的偏执狂，如果MS拥有良好的破坏事物的历史，这已经很长一段时间了！ ; - }

hth。

回复收藏 0 原文

赢得她心 2025-02-18 20:19:36

我们有同样的错误。 URL中的GUID是Azure工件饲料的传统别名。

在dotnet还原构建任务中，在失败的管道中，该字段“使用此Azure Artifacts feed中的软件包”是空白的。设置为所需的提要解决了这个问题。

“要使用”

回复收藏 0 原文

自在安然 2025-02-18 20:19:36

就我而言，我在源供稿上添加了许可，以在目标项目构建身份中授予“ Feed Reader”角色。构建身份遵循命名约定：

“ {project name}构建服务（{org name}）”

导航到feed，单击齿轮图标（feed设置），单击“权限”，然后单击“权限”，然后单击“”添加用户/组”。现在添加构建服务。

您可以在此处阅读有关它的信息： https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view = azure-devpops#pipelines-

permissions- a href =“ https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access/access-tokens?view = azure-devops＆amp; tabs = yaml#scoped-build-build-distities” noreferrer“> https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view= azure-devops& tabs = yaml#scoped-build-nidentities

消费管道可能需要运行NugetAuthenticate任务：

 - task: NuGetAuthenticate@1

In my case, I added a permission on the source feed, to grant "Feed reader" role to the target project build identity. The build identity follows the naming convention:

"{Project Name} Build Service ({Org Name})"

Navigate to the feed, click the gear icon (Feed settings), click "Permissions" and click "Add users/groups". Now add the build service.

You can read about it here: https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions

And build identities here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml#scoped-build-identities

The consuming pipeline may need to run the NuGetAuthenticate task:

 - task: NuGetAuthenticate@1

回复收藏 0 原文

宛菡 2025-02-18 20:19:36

最近刚刚遇到了同样的问题，现在似乎是由 dotnetCorecli任务：

还原和 push 此.NET核心CLI任务的命令不再采用新功能，仅处理关键的错误。有关详细信息，请参见评论。

当连接到与项目管道同一组织中的feed时，在尝试调用dotnetcorecli任务之前添加以下任务为我们解决了错误：

- task: NuGetAuthenticate@1
  inputs:
    forceReinstallCredentialProvider: false # Default, feels wrong to call without inputs

一旦我完成该任务，我需要关闭“限制工作授权范围”到当前的项目“用于发行和非发行管道的设置，或设置对提要的访问正确：

在组织或项目级别（取决于您创建的位置您的提要），创建一个新组（设置|权限|组），然后将您的项目级构建服务添加到它 - 最简单的方法是开始在用户搜索框中键入项目名称，它应该列出类似的内容。 [ProjectName]构建服务（[ORGNAME]）。

然后，您可以将小组作为“饲料读取器”添加到相关的工件供稿中。

如果您需要连接到外部组织，则可以提供 nugetserviceconnections 使用适当的个人访问令牌进行连接的列表。

Just had the same issue recently, which appears to now be caused by the important information callouts on the DotNetCoreCLI task:

The NuGet Authenticate task is the new recommended way to authenticate with Azure Artifacts and other NuGet repositories. The restore and push commands of this .NET Core CLI task no longer take new features and only critical bugs are addressed. See remarks for details.

When connecting to a feed in the same organisation as the project pipeline, adding the following task before attempting to call the DotNetCoreCLI tasks resolved the errors for us:

- task: NuGetAuthenticate@1
  inputs:
    forceReinstallCredentialProvider: false # Default, feels wrong to call without inputs

Once I'd completed that, I needed to either turn off the "Limit job authorisation scope to current project" setting for both release and non-release pipelines, or set up access to the feed correctly:

At either the Organisation or Project level (depending on where you've created your feed), create a new Group (Settings | Permissions | Groups), and add your project-level build service to it - the easiest way is to start typing the name of the project in the user search box, it should list something like [ProjectName] Build Service ([OrgName]).

You can then add the group as a "Feed Reader" to the relevant Artifact Feed.

If you need to connect to an external organisation, you can provide a list of nuGetServiceConnections that use appropriate Personal Access Tokens to connect.

回复收藏 0 原文