Issue is missing Type label, remember to add a Type label

Issue is missing Type label, remember to add a Type label

Thank you for filing this issue. If I understand correctly are refering this bold hightlighted part feed-feed-feed-feed-feed-hxxxxxrfeaturebranch as problem?
Are you using GithubAction or Azure CI pipeline? Could you please share simple repro code with you CI pipeline yml so I can reproduce it?

Using Azure CI yaml pipeline. In pipipeline approx 5 dotnet restore task there. Remaining four works fine except this task
main file is build-fb.yml
template is jobs-L1L2Test.yml getting error in this template line 137.
nuget.config file
jobs-L1L2Test.zip

check agent pool is Linux scaleset. Remaining all restore are working fine

@crsreddy1447 Please avoid using the NuGetCommand or DotnetCliCommand tasks in Azure DevOps. We reported to them a year ago that their design breaks package source mapping: microsoft/azure-pipelines-tasks#15542

They said they're looking to deprecate these commands and recommend customers use script tasks to invole msbuild, nuget.exe, or dotnet directly, and use the NuGetAuthenticate task to set up credentials for private feeds. Another customer gave a simple to understand example: microsoft/azure-pipelines-tasks#15542 (comment)

But the ticket microsoft/azure-pipelines-tasks#15542 (comment) is still in open. So we used this method by using feed as prefix. We have many dependencies on this. If we change to intead of dotnet restore lot many changes we have to do. Also in dotnet core cli we can use wildcard way ie(**/*.netcore.csproj) but in powershell we cannot use. Any way to use that?

Also in dotnet core cli we can use wildcard way ie(**/*.netcore.csproj) but in powershell we cannot use. Any way to use that?

Could you just iterate through all *.csproj in powershell to restore one by one? Even though microsoft/azure-pipelines-tasks#15542 (comment) is just single line of powershell command, you can do multiple lines of advanced powershell commands in 1 task.

I am getting error MSBUILD : error MSB1009: Project file does not exist.
Switch: *.csproj
Command used is
dotnet restore *.csproj --configfile .\nuget.config --verbosity Detailed

Finally issue resolved my removing dotNet restore task which was failing

Can you create a solution file, and add all your projects to that solution, so no file globbing is needed in the dotnet restore my.sln command line? It's a one time effort of dotnet new sln ; dotnet sln add path\to\project.csproj. The dotnet sln add can be scripted, so it doesn't need to be done manually. I'm not familiar with bash, but gci -recuse -filter *.csproj | foreach-object { & dotnet sln add $_.FullName } might work in PowerShell.

But the ticket microsoft/azure-pipelines-tasks#15542 (comment) is still in open

For better or worse, the NuGet team does not own or maintain the Azure DevOps tasks. Feel free to upvote (add a 👍 reaction) to the issue, or comment on it, but we don't have permissions to change their code. At best we can create a pull request, but that requires us to understand how it works, and re-implement their private feed permissions in a different way. Otherwise, we need to wait until they deem the issue important enough to prioritize and schedule in a sprint.

This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment.

Issue was resolved
***For single file
dotnet restore 'Test.UnitTests.csproj' --configfile NuGet.Config
***** For Wildcard
dir "/.netcore.csproj" -Recurse | %{dotnet restore $PSItem.FullName --configfile NuGet.Config}

we followed prefix method. Due to some internal props file we faced the issue. Now it was resolved. Thanks for all the responses

note that NuGet is more efficient when it runs on a solution, so it can restore projects in parallel, and cache package information in-memory, rather than running once per project. Another problem with the "run restore once per project file" approach is that NuGet will automatically restore referenced projects, meaning that every ProjectReference will cause multiple restores. The second and subsequent restore of a project will be fast, a "no-op" restore, but not needing to check for a no-op restore is faster than a doing a no-op restore.

I suggest creating a solution file and restoring that solution.