0

We added a nuget.config file to the NuGet restore task in our Azure DevOps Pipeline. We used the "browse" feature to set the path for it, but when we run the pipeline we get the error "Error: Not found nugetConfigPath". This seems to indicate the path we selected is incorrect. We have re-checked the package source paths in the .config file and have confirmed they are correct.

So far we have been unable to locate any documentation regarding this issue.

We are using TFVC.

This is the path Azure DevOps assigns when we use the "browse" feature: $/PCS Development/Forms/PCS.Forms.Integration/nuget.config

We switched the path to a different solution in a different directory and the NuGet restore task works. Then we switched it back to the solution we need to build with the same path reference $/PCS Development/Forms/PCS.Forms.Integration/nuget.config and it works. Seems like the issue is related to DevOps not always recognizing the path of the solution we need to build.

After finding the work around for the Nuget restore task we received the same pathing error in the Build task. In the build task the direct (absolute) reference D:\a\11\s\Forms\PCS.Forms.Integration\PCS.Forms.Integration.sln instead of the $/PCS Development/Forms/PCS.Forms.Integration/PCS.Forms.Integration.sln which is not working (but is working in the Nuget restore task now).

An issue has been opened with Microsoft at https://github.com/microsoft/azure-pipelines-tasks/issues/17033

Are we doing some thing wrong in the way we create the path references or is this a bug?

Tyson Gibby
  • 2,590
  • 2
  • 18
  • 37
  • Microsoft has identified the issue we are having as a bug: https://developercommunity.visualstudio.com/t/Build-using-Visual-Studio-build-started-/10163263 – Tyson Gibby Oct 20 '22 at 16:35

1 Answers1

1

I would first add a debug task to the pipeline, that would list all the contents of agent directories with something like this: https://stackoverflow.com/a/63129192/11034408

Then look from the listing what the actual path to nuget.config is. Then construct the path with predefined variables listed here: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml .

So something like:

$(System.DefaultWorkingDirectory)/PCS Development/Forms/PCS.Forms.Integration/nuget.config

Using direct paths (that do show up in pipeline logs) is not recommended as the folder structure might change. This is especially true with the self-hosted agents where build definitions get mapped to certain paths under the agent work folder but can change depending on how many agents you are running in pool, agent cleanup jobs, or something that makes the agent map the build definition again.

The nuget task behaves a bit badly with classic pipelines (which I assume you are using) as it indeed gives out a relative path. Not sure where you get that '$' in front of the path though, it probably wreaks havoc as well.

This might also help to understand the directory structure of azure pipelines agents: https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/jobdirectories.md

JukkaK
  • 1,105
  • 5
  • 15
  • This is good information. "The nuget task behaves a bit badly with classic pipelines" How do I tell if this is a "classic" pipeline? Do I recreate the pipeline instead of use the existing one to make sure it is not "classic"? – Tyson Gibby Oct 17 '22 at 14:55
  • 1
    A classic pipeline is one made with a visual editor ("Build definition"). Yaml-based pipelines are another option, with the caveat that if you are running Azure DevOps Server, you need to have at least 2020 version. I think this migration guide from classic to yaml illustrates the difference: https://learn.microsoft.com/en-us/azure/devops/pipelines/migrate/from-classic-pipelines?source=recommendations&view=azure-devops – JukkaK Oct 18 '22 at 11:58
  • 1
    I just realized that you must be using TFVC as a version control (instead of Git) - that explains the dollar sign in the path, and with TFVC, the dollar sign is of course needed. I'd recommend adding that info to to future posts, as it's helps to narrow down the issue (though probably scares off anyone who hasn't had the pleasure of working with on-premise TFS back in the days). – JukkaK Oct 19 '22 at 08:09
  • Added the TFVC information to the original post. – Tyson Gibby Oct 20 '22 at 16:36