Azure Pipelines: "Project file(s) matching the specified pattern were not found": the dotnet task matched no project
The .NET task (DotNetCoreCLI@2) turns its Path to project(s) input (projects) into a list of files by matching each line as a pattern under $(System.DefaultWorkingDirectory). When the list is empty, the build, publish, run and custom commands stop with this message (restore fails with No files matched the search pattern. for the same reason). The pattern is not printed, so look at what the task was given: most often a variable that does not exist, a backslash, or a path written from the wrong folder (a Stack Overflow question on this message has been seen over 42,000 times).
When the build is a pull request's build validation, the required build stays failed until the task finds the projects: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the pipeline is fixed. Get it on JetBrains Marketplace
What it looks like
##[error]Project file(s) matching the specified pattern were not found., with no pattern after it.- With
command: publish, it may followNo web project was found in the repository.That is the case in the publish section below. - With
command: test, the same words come as a warning, and the step passes without running any test. A green test step is not proof that tests ran.
$(Parameters.projects) that nothing defines
- A pipeline exported from the classic editor, or started from its .NET template, often has
projects: '$(Parameters.projects)'. In the classic editor that was a process parameter; in YAML nothing defines it, an unknown macro stays as written, and no file is called$(Parameters.projects). Put the pattern itself in, such asprojects: '**/*.csproj'(the accepted answer on the most read question, and on a publish question).
A backslash on a Linux agent
**\*.csprojworks on a Windows agent but matches nothing onubuntu-latest. Use forward slashes,**/*.csproj, which work on both (the most voted answer on the same question: a guide written for Windows).
The pattern starts at the repository root
- The task's own help says the pattern is matched against the root of the repository, whatever Working directory says. With the project in
src/Api/Api.csproj, writesrc/Api/Api.csprojor**/Api.csproj, notApi.csprojwithworkingDirectory: src/Api. - In a classic release, or a later stage that has only the artifact,
$(System.DefaultWorkingDirectory)holds downloaded artifacts, not the sources, so there are no project files to find. Build and publish in the build stage, and deploy the output. - If the repository has a solution,
projects: '**/*.sln'builds everything in it in one go (an answer).
publish ignores projects while publishWebProjects is on
- For
command: publish, Publish web projects (publishWebProjects) is on by default. Then the task ignoresprojectsand looks for web projects itself: a.csproj,.vbprojor.fsprojwith aweb.configor awwwrootfolder next to it, or one that uses theMicrosoft.NET.Sdk.WebSDK. - A console app, a worker or an Azure Functions project is not a web project by that test, so nothing is found. Set
publishWebProjects: falseand name the project inprojects.
Several projects, or all but some
- The input takes one pattern per line, not a list with commas or semicolons. Exclusions start with
!and come after the pattern they narrow:projects: |**/*.csproj!**/*.Tests.csproj
(a Stack Overflow answer; to keep the list in a variable, make it a multi-line variable, as in another answer). - To check, put
- script: find $(System.DefaultWorkingDirectory) -name '*.csproj'(orGet-ChildItem -Recurse -Filter *.csprojin PowerShell) before the task, and compare the paths with your pattern. See also the task's reference page.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, GitHub, Inc. or JetBrains.
More: restore stops with Unable to load the service index for source · the publish step points at a path that is not there · no zip where the deploy task looks · what the code after Failed to deploy web package means · 日本語