azure-pipelinesazure-pipelines-yamldotnet-aspire

DotNetCoreCLI@2 workload restore


After adding #Aspire to my project I needed to add the workload to the Azure Hosted Agent. Initially, according tot the documentation I added the following:

- task: DotNetCoreCLI@2
displayName: "dotnet workload restore"
# dotnet workload restore [<PROJECT | SOLUTION>...] [options]
inputs:
    command: 'custom'
    custom: 'workload restore'
    projects: '$(solution)'

Result:

Starting: dotnet workload restore
==============================================================================
Task         : .NET Core
Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version      : 2.240.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
/usr/bin/dotnet workload restore /home/vsts/work/1/s/Solution.sln
Could not execute because the specified command or file was not found.
Possible reasons for this include:
  * You misspelled a built-in dotnet command.
  * You intended to execute a .NET program, but dotnet-workload restore does not exist.
  * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[error]Dotnet command failed with non-zero exit code on the following projects : [ '/home/vsts/work/1/s/Solution.sln' ]
Finishing: dotnet workload restore

I have tried some other variations but none seem to work. Is there a way to make it work using the DotNetCoreCLI@2 task?

Currently reverting to using:

       - task: CmdLine@2
        displayName: "dotnet workload restore"
        inputs:
          script: 'dotnet workload restore'

Solution

  • Is there a way to make it work using the DotNetCoreCLI@2 task?

    I tested the issue and found that we can use the DotNetCoreCLI@2 task to do the dotnet workload restore as the following yaml.

    - task: DotNetCoreCLI@2
      displayName: "dotnet workload restore"
      inputs:
        command: 'custom'
        custom: 'workload'
        arguments: 'restore $(solution)'
    

    Test result:

    enter image description here

    Update:

    I tried that before, and I get this exception:

    /usr/bin/dotnet workload restore **/*.sln 
    Unhandled exception: Microsoft.Build.Exceptions.InvalidProjectFileException: The project file could not be loaded. Could not find a part of the path '/home/vsts/work/1/s/**/*.sln'. /home/vsts/work/1/s/**/*.sln` 
    

    The error indicates that the use of wildcards (**) in paths might not be supported by the dotnet workload restore command. You can use the direct path of the solution. For example, when my solution file is in the code folder, use the following yaml.

    enter image description here

    variables:
      solution: "code/AspireSample.sln"
    steps:
    - task: DotNetCoreCLI@2
      displayName: "dotnet workload restore"
      inputs:
        command: 'custom'
        custom: 'workload'
        arguments: 'restore $(solution)'
    

    Removing the '$(solution)' does work however

    From the argument PROJECT | SOLUTION, if a file is not specified, the command searches the current directory for one.

    When I put the solution file in the root of the directory and remove the $(solution), it works. If the solution file is not in the root directory, removing the $(solution) will cause this error: Couldn't find a project.