31

I'm having a problem (unwanted behavior) when running an Azure Build Pipeline with the following project/folder structure.

My repository's root folder has two main folders:

  • frontend (ASP.Net Core 2.x & Angular 7 project)
  • backend (ASP.Net Core 2.x)

I'm trying to build two separate Azure Pipelines one for the backend and one for the frontend, so I use the projects: parameter to specify the correct path.

The build and test commands are running fine and are only restoring/building/testing the backend folder, but the publish command is running for both folders: backend & frontend.

This is my yaml file:

 #build backend project
 task: DotNetCoreCLI@2
   displayName: dotnet build --configuration $(buildConfiguration)
   name: BuildBackendProject
   inputs:
     command: build
     projects: '**/backend/**/*.csproj'
     arguments: '--configuration $(buildConfiguration)'

 ... #run some tests

 #publish backend project
 task: DotNetCoreCLI@2
   displayName: dotnet publish backend --configuration $(buildConfiguration)
   name: PublishBackendProject
   inputs:
     command: publish
     projects: '**/backend/**/*.csproj'
     publishWebProjects: True
     arguments: '--configuration $(BuildConfiguration) --output 
     $(Build.ArtifactStagingDirectory)/backend'
     zipAfterPublish: True

I tried different folder paths but it's always running two publish commands.

If I run locally in CMD dotnet publish backend (from repo's root folder) it works fine but apparently that doesn't work with the Azure Pipeline.

Any ideas or fixes greatly appreciated.

Federico Rodriguez
  • 398
  • 1
  • 3
  • 8
  • try using 'backend/**/*.csproj' instead of '**/backend/**/*.csproj' – D.J. Nov 17 '18 at 14:00
  • @D.J. I tried with your suggestion and even using a specific project instead of a wildcard, but it's still running both publish commands. _[command]/usr/bin/dotnet publish /home/vsts/work/1/s/frontend/GaiaFront.Web.csproj_. This last command shouldn't execute if it worked like the build, test and restore commands. – Federico Rodriguez Nov 17 '18 at 16:38

1 Answers1

71

The trick is in using the publishWebProjects/projects properties. Those are actually mutually exclusive. If the publishWebProjects is used, the projects property value is skipped.

From the documentation:

Publish Web Projects*: If true, the task will try to find the web projects in the repository and run the publish command on them. Web projects are identified by presence of either a web.config file or wwwroot folder in the directory.

So you could try the following code for publishing:

task: DotNetCoreCLI@2
  displayName: dotnet publish backend --configuration $(buildConfiguration)
  name: PublishBackendProject
  inputs:
    command: publish
    projects: '**/backend/**/*.csproj'
    publishWebProjects: false
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/backend'
    zipAfterPublish: true
Herman Cordes
  • 4,628
  • 9
  • 51
  • 87
  • 2
    Thanks, @HermanCordes! Missed that part of the docs. It correctly executed the publish command for the _backend_ folder. The only thing is that it built the zips for *all the projects* (web & class libraries) in that folder. I could make the release pipe to get only the _web project_ for the drop folder, but considering that I only need to build the web project I changed the `projects:` argument to the specific path. – Federico Rodriguez Nov 20 '18 at 18:20
  • 14
    Thanks, setting publishWebProjects to false was the key to fixing my woes. Might just be me but it's not clear this defaults to true from the docs. – Tristan Channing Nov 23 '18 at 10:26
  • 3
    I agree, just spent an hour trying to figure out why a simple 'dotnet publish' wouldn't work for a build due to it defaulting to true and only grabbing the one web csproj in the solution. – playsted Mar 18 '19 at 23:38
  • 5
    If they are mutually exclusive it would be nice if we got even just a warning saying projects 'xyz' will be ignored, as publishWebProjects has been set to true, instead of such a silent ignore of a key configuration paramater. – Josh Mc Feb 24 '21 at 03:58
  • 5
    what a misleading property name!!! spent hours figuring this out. – Ross Brigoli Apr 14 '21 at 16:04
  • 1
    [github issue](https://github.com/microsoft/azure-pipelines-tasks/issues/15874) to improve this as I too spent way too much time trying to understand the behavior here – spottedmahn Feb 03 '22 at 14:33
  • 1
    @spottedmahn: Thanks for adding that. I strongly support your suggestion. Unfortunately, it looks like your proposal was tagged as 'stale'. – Jim G. Oct 19 '22 at 18:01