Azure pipeline for Azure Function does not find project

Question

I've got a build pipe for an Azure Function using .Net Core 3.1.x. All the steps until the publishing are doing fine. I can get the publish step working by using script, but not through the yaml task. What am I missing?

Script (works)

 - script:  dotnet publish --configuration Release .\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj

Task (does not work)

- task: DotNetCoreCLI@2
  displayName: 'Publish Project'
  inputs:
    command: 'publish'
    configuration: 'Release'
    projects: '.\af-process-mds-vehicle-output-to-deviation\af-process-mds-vehicle-output-to-deviation.csproj'
    zipAfterPublish: true

It doesn't find the project. Here's the error message.

2021-10-29T05:21:44.3024816Z ##[section]Starting: dotnet publish
2021-10-29T05:21:44.3150367Z ==============================================================================
2021-10-29T05:21:44.3150726Z Task         : .NET Core
2021-10-29T05:21:44.3151190Z Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2021-10-29T05:21:44.3151475Z Version      : 2.187.0
2021-10-29T05:21:44.3151733Z Author       : Microsoft Corporation
2021-10-29T05:21:44.3152035Z Help         : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2021-10-29T05:21:44.3152373Z ==============================================================================
2021-10-29T05:21:44.7797987Z [command]C:\Windows\system32\chcp.com 65001
2021-10-29T05:21:44.7903026Z Active code page: 65001
2021-10-29T05:21:44.7927221Z 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.
2021-10-29T05:21:44.8938257Z ##[error]No web project was found in the repository. Web projects are identified by presence of either a web.config file, wwwroot folder in the directory, or by the usage of Microsoft.Net.Web.Sdk in your project file. You can set Publish web projects property to false (publishWebProjects: false in yml) if your project doesn't follow this convention or if you want to publish projects other than web projects.
2021-10-29T05:21:44.9001249Z 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://learn.microsoft.com/en-us/dotnet/core/tools/ and https://learn.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
2021-10-29T05:21:44.9003648Z ##[error]Project file(s) matching the specified pattern were not found.
2021-10-29T05:21:44.9182124Z ##[section]Finishing: dotnet publish

After the tips from the answer I got the pipe working. Here's the full working pipe. (Still don't know why it didn't work earlier.)

Working pipe:

name : af-vehicle-sync-to-deviation

## if there is a change is the deviation folder for the main branch. Then trigger. 
trigger:
  branches:
    include:
      - main
  paths:
    include:
      - af-process-mds-vehicle-output-to-deviation/*

pool:
  vmImage: 'windows-latest'

variables:
  buildConfiguration: 'Release'
  SolutionPath: '**\*.sln'
  
stages:
- stage: Build
  displayName: Build solution
  jobs:  
  - job: Build

    displayName: Build and publish solution
    steps:
      - checkout:  self
      - task: NuGetToolInstaller@1

      - task: NuGetCommand@2
        inputs:
          restoreSolution: $(SolutionPath)

      - task: UseDotNet@2      
        inputs:
          packageType: 'sdk'
          version: '3.1.x'
        displayName: 'Use .NET Core SDK 3.1.x'
 
      - task: DotNetCoreCLI@2
        inputs:
          command: 'build'
          configuration: $(buildConfiguration)
          projects: '$(SolutionPath)'
        displayName: 'Build solution'
        
      - task: DotNetCoreCLI@2
        displayName: 'Publish Project'
        inputs:
          command: 'publish'
          configuration: 'Release'
          projects: '**\*.csproj'
          publishWebProjects: false
          zipAfterPublish: true
          arguments: '--output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'

      - task: PublishBuildArtifacts@1
        inputs:
          PathtoPublish: '$(Build.ArtifactStagingDirectory)'
          ArtifactName: 'drop'
          publishLocation: 'Container'

Matt Stannett · Accepted Answer · 2021-10-29T19:53:38.587

You could use '**/*.csproj' but honestly, I would do something like this answer and add a script to list out all the files and folders recursively before this step that fails.

Assuming that you have a restore or build step before this publish you could add it after those, or just as the first step after your checkout one.

You can also inspect the logs of earlier steps to see the file path/s., instructions on doing this are available here.

Using $(System.DefaultWorkingDirectory) as your root is also recommended, rather than .\, so you would have '$(System.DefaultWorkingDirectory)\af-process-mds-vehicle-output-to-deviation...'.

Edit

If you look at the logs for your build step you will see entries like /home/vsts/work/1/s/XXX.YYY.ZZZ/XXX.YYY.ZZZ.csproj that refer to the different projects inside your solution. By default most commands will be run in $(System.DefaultWorkingDirectory) which would equate to /home/vsts/work/1/s/ in this instance, you can think of it as the root of your repository - there is more information on this structure here.

The error you were encountering is actually about the lack of a web project, rather than a path issue though, for the build step it is best practice to use the --output <output-directory-here> flag to output the compile files into a specific folder, that way you can easily publish that folder.

Exactly, I do a restore before. Updated the post with full pipe. — Cedervall, Oct 29 '21 at 11:44

Azure pipeline for Azure Function does not find project

1 Answers1