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

[stevewillcock]

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.

[hiyadav]

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

[stevewillcock]

Ah, thanks for the clarification. It would be good to clear up the documentation around this (unless I missed something already in the docs). If adding / rationalising these features takes a while then documentation would prevent wasted time wondering why things didn't work :)

Thanks!

[ggirard07]

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...

[MarkKharitonov]

Is there any ETA on this?

[NickDarvey]

...?

[bishal-pdMSFT]

@ggirard07 if I understand correctly, you want to build all projects (**/*.csproj) in the sub-tree of a particular directory. For that you can use an appropriate minimatch pattern which will match all csproj files under a directory. I believe something like **/<directory-name>/**/*.csproj

[MarkKharitonov]

The minimatch pattern is not adequate when order matters. Which in case of projects can be resolved if they belong to the same solution (in which case - why build projects and not the solution)?
However, in my case I need to build solutions and there is no way to specify order with minimatch. Using it produces wrong order, actually.

[bishal-pdMSFT]

That's interesting @MarkKharitonov. I am afraid this scenario is something the task might not been thought for.
Can you not have a number of tasks one after another in right order? Or do you have huge number of solutions?

[MarkKharitonov]

Just 6. I am using a YAML template which is given an array of solutions and it iterates over them invoking the task for each solution individually. While doing it we need to pass workingDirectory, which is not respected. So, we modify the path given to the projects parameter. Which in turn fails if the path starts with a dot. But this is another issue - https://github.com/microsoft/azure-pipelines-tasks/issues/12717

[ggirard07]

@bishal-pdMSFT The step is part of a template we use for every repo checked-out with the multi-repo checkout principle.
In that case we cannot hard-code path relative to System.DefaultWorkingDirectory because we need each step in the template to be contextualized to the current repo root, which is $(Agent.BuildDirectory)/{repo-alias}.
The easiest solution in that case is to pass the current repo path as a parameter to the template, then use this parameter either to populate the workspaceDirectory anywhere it is supported, which apparently is not the case of the DotNetCoreCLI task.

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[MarkKharitonov]

Is it that hard to fix?

[mihai-cindea]

Bump.
Hit this on a multi repository pipeline which has a custom pack command. Any plans to fix it any time soon?