azure-pipelines-tasks: "workingDirectory" parameter seems to be ignored for DotNetCoreCLI@2 "dotnet restore" task

Question, Bug, or Feature?
Type: Bug

Enter Task Name: DotNetCoreCLI@2

Environment

Server - Azure Pipelines

Issue Description

Running build (for example) with the following configuration specifying a workingDirectory works as expected:

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    workingDirectory: 'src'

but running restore with the following similar configuration fails to find a project / solution file

- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    workingDirectory: 'src'

This fails with:

MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.

It seems as if the restore task is ignoring the workingDirectory parameter

Task logs

[command]"C:\Program Files\dotnet\dotnet.exe" restore --configfile d:\a\1\Nuget\tempNuGet_31.config --verbosity Detailed
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
##[error]Packages failed to restore
##[section]Finishing: DotNetCoreCLI

Error logs

MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 18
Comments: 30 (8 by maintainers)

Most upvoted comments

quack

+10

NickDarvey on Aug 9, 2021

Is it that hard to fix?

MarkKharitonov on Nov 30, 2020

Is there any update on this ticket? If the workingDirectory is not going to be honoured, then the documentation available should at least be updated to specify: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops

workingDirectoryWorking Directory | Current working directory where the script is run. Empty is the root of the repo (build) or artifacts (release), which is $(System.DefaultWorkingDirectory)

sofcal on Jun 15, 2022

I am currently seeing the same behavior for build command. The value of workingDirectory is being ignored and default back to the value of System.DefaultWorkingDirectory.

This is critical with the introduction of multi-checkout where we have sources in multiple path and projects needs to remain a generic wildcard (like **/*) in order to go through the list of checked-out repositories.
The only solution I currently see is to move away from the DotNetCoreCLI task and rely only on some PowerShell script with the native .Net Core CLI…

ggirard07 on Feb 13, 2020

If it is not possible to fix it can we at least get a warning that we use parameter which is not supported for specific commands?

kmadof on Mar 9, 2022

Issue is still relevant.

ChristoWolf on Jan 11, 2023

The workingDirectory parameter is also ignored when using the test command.

ChristoWolf on Mar 1, 2022

Hey @stevewillcock

You’re correct, the restore, pack and push commands don’t honour workingDirectory input. Which is causing this issue, you can however use projects input to give paths to projects or wildcards.

This seems to be in accordance to this issue, hence referencing: #9789

hiyadav on Jul 25, 2019

Yawn, yet another task where the custom option actually works a lot better than the build-in commands…

The following works for restore, build, test and will automatically restore/build/test any projects in $(some-directory) as you would expect (and how the cli behaves).

- task: DotNetCoreCLI@2
  displayName: 'DotNet Restore'
  inputs:
    command: custom
    custom: 'restore'
    workingDirectory: $(some-directory)

robmaas on Mar 22, 2023

I just wasted a considerable amount of time because of this issue. Any update?

roelofvdv on Feb 14, 2023