Azure-pipelines-tasks: Running a dotnet restore in DotNetCoreCLI@2 does not respect "configuration" or "arguments" inputs

[codyconfer]

Bug

DotNetCoreCLI@2

Environment

• Azure Pipelines, flyfrontier, FlyFrontier Service Layer, F9.Api Validation/19052852:

• Hosted, Windows Container

Issue Description

Running a dotnet restore using the DotNetCoreCLI@2 task ignores critical inputs set on the task.
variable definitions:

  buildConfiguration: "Release"
  feedRestore: "F9Beta"

 - task: DotNetCoreCLI@2
    inputs:
      command: 'restore'
      projects: '**/*/*.csproj'
      feedsToUse: 'select'
      vstsFeed: $(feedRestore)
      versioningScheme: 'off'
      configuration: '$(buildConfiguration)'
      arguments: '/property:Configuration=Release'

My issue is that I have a conditional PackageReference that is only included in the Release build configuration. Enforced in the csproj with:

<PackageReference Condition="'$(Configuration)' == 'Release'" Include="PackageName" Version="*" />

It seems that MSBuild is defaulting to debug. I have tried 2 ways laid out in the documentation to set the build configuration to release. It seems that when running restore, The task completely ignores configuration and arguments inputs. I am using a private nuget feed, so I am having authorization issues outside of the task, but it seems that the task does not allow for the setting of a build configuration. Currently I am stuck on how to proceed. I would assume the expected behavior is for the task to at least respect the arguments input. If this assumption is incorrect, this can be considered a feature request.

the command in the logs is written as:

[command]D:\_work\_tool\dncs\2.2.300\x64\dotnet.exe restore D:\_work\1\s\F9.Api.TokenQueries\F9.Api.TokenQueries\F9.Api.TokenQueries.csproj --configfile D:\_work\1\Nuget\tempNuGet_41917.config --verbosity Detailed

Which is what leads me to believe that /property:Configuration=Release is being ignored.

Task logs

log_restoreNUGET.zip
log_installDOTNET.zip

[codyconfer]

Found the documentation I needed:
docs.microsoft.com

If anyone is in a similar situation, this is a workaround:

add NuGet.Config

authenticate feeds manually

- task: NuGetCommand@2
    inputs:
      command: 'custom'
      feedsToUse: 'select'
      versioningScheme: 'off'
      arguments: 'sources update -Name $(feedRestore) -Username "vsts" -Password "$(System.AccessToken)" -StorePasswordInClearText  -ConfigFile "config file path"'

-StorePasswordInClearText is needed for DotNetCoreCLI@2 to access, but is thrown out after agent is disposed. Not ideal, but works.

use custom command dotnet task:

- task: DotNetCoreCLI@2
    inputs:
      command: 'custom'
      projects: '**/*/*.csproj'
      custom: 'restore'
      arguments: '--configfile "config file path" /property:Configuration=$(buildConfiguration)'
      versioningScheme: 'off'
      feedsToUse: 'select'

You can also point dotnet build and publish to the nuget config and those will run in release if you don't want a dedicated step for a nuget restore. I like the granular level so that I know exactly where something failed before digging into logs, but to each their own.

I will leave this opened because I think the task should respect a build configuration that is passed in, but this work around has me up and running. If the team feels this should be closed, go for it.

[hiyadav]

Hey @codyconfer

Thanks for sharing the issue with such details. It's unfortunate that you had to face this, but i see you got a work around.
Another possible work around for this can be , if you're using dotnet version 2.0 or above then you can directly use _dotnet build -c configuration_ as this does an implicit restore for the right configuration.

Configuration as an argument is not supported by dotnet cli for restore command. Hence is not passed as an argument to dotnet cli.
We can however consider including '_Arguments_' for dotnet restore command.

[codyconfer]

@hiyadav thanks for the quick response. It makes sense that the configuration input wouldn't be available, but the arguments would be nice to pass in ms build parameters. I also linked this to an open issue in the docs repo. Both the .NET Core and .NET Core Cli build task pages reference the same tool, the answer to my issue (custom command usage) was explicitly stated in the .NET Core page but I was referencing the .NET Core Cli page and didn't know the other existed.

Implementing the work around to use arguments:

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

to

- task: DotNetCoreCLI@2
    inputs:
      command: 'custom'
      custom: 'restore'

This isn't a huge deal, but where it becomes problematic is when restoring from a protected azure artifacts feed. Restore handles authentication where as custom does not.

This was one of the issues I was having, authenticating my feed for subsequent steps so that I could run dotnet build -c or dotnet publish -c. I figured out how to do the authentication in this as well, so a lot of it was just me getting over the azure pipeline yaml learning curve. There is an open issue in docs to outline authenticating artifacts feeds, so you guys are already all over that.

I would like to thank the team for the work they have done, I was working with pipelines in January and hadn't touched it much since then. The progress made in pipelines over the past few months is incredible.

[hiyadav]

Adding @jotaylo, for considering taking arguments as an input for restore command.

@jotaylo added you based on the history of restorecommand.ts file.

[joeyj-msft]

Adding to the conversation, this issue prevents usage of the lock file mentioned here: https://blog.nuget.org/20181217/Enable-repeatable-package-restores-using-a-lock-file.html

[bishal-pdMSFT]

@elbatk is this something you should consider?

[elbatk]

This is likely something we will not fix. We are taking on work this quarter to deprecate a few of our Pipelines tasks (this one included) in favor of just using out new authentication tasks and then custom scripts. That way you can ensure you have the latest tooling that all behaves as normally as possible. So the flow would be: 1. get the tools 2. run NuGetAuthenticate 3. run a custom script with your dotnet command. Going to close this, if someone finds this new way that I've described does not work then please let me know.