I'm trying to deploy a .NET application using an Azure DevOps pipeline by making use of an ARM template and storing the template in an Azure git repository.
##################yml file for the pipeline build####################
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**\*.csproj'
arguments: '-c Release'
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: true
arguments: '-o $(Build.ArtifactStagingDirectory)/web'
- task: CopyFiles#2
inputs:
sourceFolder: 'appdeploy/'
TargetFolder: '$(Build.ArtifactStagingDirectory)/appdeploy'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
I am getting an error in the build step of the pipeline saying:
DotNetCoreCLI: If you're using Publish command with -o or --Output argument, you will see that the output folder is now being created at root directory rather than Project File's directory.
##[error]Project file(s) matching the specified pattern were not found.
According to the error message , this issue exists in the “build” step.
You need to define in the build task which .csproj files you want to build.
In your case, the definition path projects: '**\*.csproj' has some issues.
You could use the projects: '**/*.csproj’ to replace it.
Note: The cause of this issue is the backslash.
Hope this helps.
Related
We have a durable function that executes multiple processing steps in a specific order, using the Function Chaining pattern.
Since the Function App has 2 clients, 2 orchestrators and multiple activities, the folder structure of our solution is as shown in the screenshot below
Since all of our code is in a Git Repo in Azure DevOps, we use a CI/CD process with Azure Pipelines, to build the solution for every new PR created, and after a new version of the development branch is created, we have a release pipeline that should continuously deploy the new version to our staging environment in Azure.
The build pipeline looks like this:
variables:
- name: BuildConfiguration
value: Release
trigger:
branches:
include:
- main
- develop
pool:
vmImage: windows-latest
jobs:
- job: 'CI_Job'
displayName: 'Build and Publish Function App'
continueOnError: false
steps:
- checkout: self
clean: true
- task: UseDotNet#2
displayName: 'Install .NET SDK'
inputs:
packageType: 'sdk'
version: '6.x'
- task: DotNetCoreCLI#2
displayName: 'Restore NuGet Packages'
inputs:
command: 'restore'
projects: '**/*.csproj'
- task: DotNetCoreCLI#2
displayName: "Build Solution"
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration $(BuildConfiguration) --no-restore'
- task: DotNetCoreCLI#2
displayName: "Run Unit Tests"
inputs:
command: 'test'
projects: 'test/**/*Tests.csproj'
arguments: '--no-restore'
testRunTitle: 'Test Functions'
- task: DotNetCoreCLI#2
displayName: "Publish Solution"
inputs:
command: 'publish'
projects: '**/*.csproj'
publishWebProjects: false
modifyOutputPath: false
zipAfterPublish: true
arguments: --configuration $(BuildConfiguration) --no-restore --no-build --output $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts#1
displayName: "Publish Build Artifacts"
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: '$(Build.Repository.Name)'
publishLocation: 'Container'
The release pipeline looks like this:
The problem is, the deployment seems to run successfully (the logs dont show any erros and even in the Deployment Center in Azure everthings looks good), but there are no functions listed in the Function App in Azure after the deployment is done.
What we have tried so far:
The release pipeline automatically sets the value WEBSITE_RUN_FROM_PACKAGE=1, we also checked that in the Azure portal to verify the value for this setting is as expected.
We also tried to execute a remote build by setting the value SCM_DO_BUILD_DURING_DEPLOYMENT=true in our appsettings in Azure.
When we deploy the Function App with a ZIP deployment from Visual Studio, everything works as expected.
We have another Function App that gets deployed to a deployment slot where the release pipeline does basically the same (except that it does deploy to a slot, not the Function App itself) where everything works fine. But we can't find the issue here.
So my question is what are we doing wrong or what are we not aware of?
Any advice would be highly appreciated!
After taking a deeper look into the artifact created by the build pipeline I could resolve the issue.
Since the production code is in the src folder and the dotnet publish task was not restricted to only publish content inside that folder, I ended up getting a ZIP folder containing all the DLLs of the solution, and inside that another ZIP folder containing the function.json files as well as the bin folder.
After adjusting the dotnet publish task as follows
- task: DotNetCoreCLI#2
displayName: "Publish Solution"
inputs:
command: 'publish'
projects: 'src/**/*.csproj'
publishWebProjects: false
modifyOutputPath: false
zipAfterPublish: true
arguments: --configuration $(BuildConfiguration) --no-restore --no-build --output $(Build.ArtifactStagingDirectory)
I had a much smaller artifact, containing only the function.json files for my functions (inside their corresponding folders) as well as the bin folder containing the other DLLs.
I'm very new to this pipeline and i'm trying to build a automated way to build the .msi installer file for my application.
I have 2 projects .Net Core and Python, so i created 2 pipelines. The .Net Core pipeline will build and save the files in a location and Python pipeline uses those files(from location) for its dependency and builds a new .msi file, the last portion in the pipeline newsetup.py builds the .msi to which i'll be passing the location of the output files of .Net Core pipeline.
The error i get is Artifact dropcli was not found for build 150.
.Net Core pipeline script:
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(Build.ArtifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(Pipeline.Workspace)'
artifact: 'dropcli'
publishLocation: 'pipeline'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
Python pipeline script:
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'current'
artifactName: 'dropcli'
targetPath: '$(Pipeline.Workspace)'
- task: PythonScript#0
inputs:
scriptSource: 'filePath'
scriptPath: 'src/python/newsetup.py'
arguments: 'bdist_msi $(Pipeline.Workspace)'
Also if i specify the build number somewhere won't it be an issue when a new pipeline is created? Or is that an limitation?
In your DownloadPipelineArtifact#2 task, the value of buildType is current. This means that you are downloading the artifact in the current run. You should set buildType to specific. Here is an example to download the latest artifact from a specific pipeline:
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'specific'
project: '{project id}'
definition: '{pipeline id}'
buildVersionToDownload: 'latest'
artifactName: 'dropcli'
targetPath: '$(Pipeline.Workspace)'
You can click "Settings" at the top of the task, it will help you to complete your task more easily.
Click Download Pipeline Artifacts task for detailed information about arguments of this task.
If i specify the build number somewhere won't it be an issue when a new pipeline is created? Or is that an limitation?
As mentioned above, you don't need to specify the build number, and what you need to specify is the pipeline definition id. You can either download the latest artifact of a pipeline or the artifact of a specific build of a pipeline.
Because Azure AppServices doesn't (anymore) support .NET Core 2.1 on x64 with framework-dependent deployments, we are currently publishing self-contained win-x64 versions of our .NET Core 2.1 Web API.
I'm trying to setup an Azure Pipeline in Yaml for CI/CD purposes and deploy it to Azure App Service deployment slot.
The issue I'm trying to resolve is this error-message: project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'
/usr/bin/dotnet publish /home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj --configuration Release -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output /home/vsts/work/1/a/MyApp.WebApi
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
/usr/share/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file '/home/vsts/work/1/s/MyApp.WebApi/obj/project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'win10-x64' in your project's RuntimeIdentifiers. [/home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj]
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1
This is my yaml file:
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- develop
pool:
vmImage: 'ubuntu-20.04'
variables:
buildConfiguration: 'Release'
buildPlatform: x64
steps:
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
- task: DotNetCoreCLI#2
displayName: dotnet publish
inputs:
command: 'publish'
publishWebProjects: true
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
arguments: '--configuration $(BuildConfiguration) -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'MyAppWebApi'
I tried modifying the CSPROJ file by adding these:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
**<RuntimeIdentifiers>win10-x64;win-x64</RuntimeIdentifiers>**
and
<PlatformTarget>x64</PlatformTarget>
Please delete the obj and bin folders from your project. Also the <TargetFramework> in your .csproj file was singular. Please try to add an "s" and it become "TargetFrameworks" to see if it works.
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1</TargetFrameworks>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
You could refer to this thread for more possible solutions.
BTW, there are different build environment between Microsoft-hosted Windows-2019 agents(which install Visual Studio Enterprise 2019) and your local machine, you could try to use self-hosted Windows agents to build your project without additional environment preparation steps.
A few things went wrong during my work. The most important one is that all the changes I've tried to make were pushed to the Develop-branch while the Pipeline was running on a different branch. My inexperience with Pipelines (and also Git) mainly caused this. I was under the impression that the trigger line in YAML pointed to the repository to restore and publish.
I finally got it working with the following steps. Like Edward Han mentioned, I tried to restore and publish by command line on my local machine. These also gave me some errors I needed to fix. Like adding this line to all (30+) referenced csproj files:
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
Then add this configuration to the webproject csproj:
<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
Then my final YAML file is this:
trigger:
- develop
pool:
vmImage: 'windows-2019'
variables:
buildConfiguration: 'Release'
buildPlatform: x64
steps:
- task: UseDotNet#2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
version: 2.1.x
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: 'restore'
projects: '**/*.csproj'
arguments: '-r win-x64'
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
- task: DotNetCoreCLI#2
displayName: dotnet test
inputs:
command: 'test'
projects: '**/*[Tt]ests/*.csproj'
arguments: '--configuration $(BuildConfiguration)'
testRunTitle: 'dotnet test 2'
- task: DotNetCoreCLI#2
displayName: dotnet publish
inputs:
command: 'publish'
publishWebProjects: true
arguments: '--configuration $(BuildConfiguration) -r win-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'MyAppWebApi'
Few important things I changed/added:
Explicitly tell to use .NET Core 2.1.*
Add -runtime parameter to the RESTORE command
Conslusion
Although I studied some Pluralsight courses, YouTube video's and blogs, I still ended up reading the Microsoft Docs/MSDN. Being used to use publishing by the Visual Studio User Interface, switching to command-line really was a big difference. A lot more depencenies are needed to be looked at. Tip: really read the urls these error messages provide, they do contain enough information to resolve your issue. At least, that's what I learned.
I'm trying to use Azure Pipelines for the first time and have finally managed to configure my azure-pipelines.yml file so it runs tests and should automatically deploy if the tests pass. However, I'm receiving this error:
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
- task: AzureRmWebAppDeployment#4
displayName: 'Azure App Service Deploy: ThermostatTestProject'
inputs:
azureSubscription: <mySubscription>
WebAppName: <myWebAppName>
packageForLinux: '$(build.artifactstagingdirectory)/**/*.zip'
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
I'm using a Mac - does anyone know how I can edit the yml file to make sure that it's Mac compatible and to get rid of this warning? I've been searching all day and cannot find a solution :(
Thank you
Trying to automate deployment with Azure Pipelines but warning due to not using Windows?
That because the task Index Sources & Publish Symbols task was written for Windows only not for Linux. When you execute this build pipeline on the agent ubuntu-latest, you will get that error.
So, this issue is not about Mac compatible but that task not compatible with Linux.
For this issue, MS replied:
Currently we don't support publishing symbols from a Linux machine.
What you could do is use SourceLink to index as usual as part of your
build and then have a job that runs on Windows to publish the symbols.
When we look at support *.snupkg packaging we will look to address the
Linux symbol publishing scenario.
Ticket here: https://github.com/MicrosoftDocs/vsts-docs/issues/3041
Besides, if you do not need to publish symbols from a Linux machine, you can disable this task.
Hope this helps.
To try to make it short, I have a React application that's build on Azure DevOps Build Pipeline like so
trigger:
- Release
queue:
name: Hosted
demands: npm
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm ci
npm run build
displayName: 'Do npm ci and build'
This does what the build would do locally too. Locally the results of build go to build directory (unzipped).
Now when I try to create release pipeline there isn't an artifact to be found using Azure Deploy Web Service task.
If I try to add PublishPipelineArtifact#0 to the build pipeline to create a publication, the YAML editor just tells string does not match pattern... and doesn't let save the definition.
I suppose I should zip the contents of the generated build directory, but what would be the right way? Also, Is using the Azure App Service Deploy task the right way to deploy Azure WebApp? It works for ASP.NET Core apps so it finds the code drop artefact (zipped) and deploys it.
<edit: Adding
- task: PublishPipelineArtifact#0
inputs:
artifactName: 'drop'
targetPath: '$(Build.ArtifactStagingDirectory)/build'
Can actually be saved and the build run. Though it errors with
2019-01-25T22:42:27.6896518Z ##[section]Starting:
PublishPipelineArtifact 2019-01-25T22:42:27.6898909Z
============================================================================== 2019-01-25T22:42:27.6898962Z Task : Publish Pipeline Artifact
2019-01-25T22:42:27.6899006Z Description : Publish Pipeline Artifact
2019-01-25T22:42:27.6899034Z Version : 0.139.0
2019-01-25T22:42:27.6899062Z Author : Microsoft Corporation
2019-01-25T22:42:27.6899090Z Help : Publish a local directory
or file as a named artifact for the current pipeline.
2019-01-25T22:42:27.6899137Z
============================================================================== 2019-01-25T22:42:28.0499917Z ##[error]Path not exist: D:\a\1\a\build
2019-01-25T22:42:28.0708878Z ##[section]Finishing:
PublishPipelineArtifact
< edit 2: It appears removing the /build does the trick. Feels a tad odd since this is what's produced locally. It doesn't produce a zip file which is expected by the release job, namely Azure App Service Deploy.
Have to examine this problem later today (two o'clock at night here).
There was another problem: The script ran only npm ci and didn't run the building part. Separating it to two different steps made the difference. It appears PublishPipelineArtifact#0 in this case isn't an ideal option if I'd like to have the results as zipped to the staging area.
A currently working solution seem to be
resources:
- repo: self
trigger:
- Release
queue:
name: Hosted
demands: npm
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm ci
displayName: 'npm ci'
- script: |
npm run build
displayName: 'npm run build'
- task: ArchiveFiles#2
displayName: 'Archive files'
inputs:
rootFolderOrFile: '$(System.DefaultWorkingDirectory)/build'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/artifact.zip'
replaceExistingArchive: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
Maybe this can be simplified, but works for now and is flexible, it feels.