I have an ASP.NET Core project in Azure DevOps repository and it gets built OK using the DevOps build pipeline. However, the release over that builds always fails with this error:
No package found with specified pattern.Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job.
More Details:
# 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:
branches:
include:
- release/*
pool:
vmImage: 'windows-2022'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
projectName: '**/F11.Web.csproj'
runtime: 'win-x64'
steps:
- task: UseDotNet#2
displayName: 'Use .NET 5 SDK (preview)'
inputs:
packageType: 'sdk'
version: '5.0.100-rc.1.20452.10'
vsVersion: '16.8.0'
includePreviewVersions: true
- task: DotNetCoreCLI#2
inputs:
command: 'restore'
projects: '$(projectName)'
feedsToUse: 'select'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '$(projectName)'
arguments: '--no-restore'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: test
projects: '$(projectName)'
arguments: '-l "console;verbosity=detailed"'
- task: DotNetCoreCLI#2
displayName: 'Publish WebApi'
inputs:
command: publish
publishWebProjects: false
projects: '$(projectName)'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory) --runtime -r $(runtime)'
- task: CopyFiles#2
inputs:
Contents: '**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(Pipeline.Workspace)'
artifactName: 'PublishBuildArtifact'
Azure DevOps pipeline release Error: No package found with specified pattern:
First, you could make sure you have generated the artifact for your build pipeline, check it from the build history in the build pipeline.
Second, when you using the release pipeline to deploy the artifact, you need make sure you have select the correct build pipeline.
Third, set the correct configuration for the task IIS web app deploy:
If above not help you, please share the configuration for the task IIS web app deploy with image in your question.
Related
Visual Studio 2019
.NET 5 WebApplication
Azure Devops Build Pipeline
Disclaimer: I initially wrote this question for the MS Developer Community, but quickly realized I do not have weeks to spend on this so I came to the experts over here on Stack. I have researched this issue through and through... I have tried so many different combinations of the publish command and arguments without ANY success.
I am building a .NET 5 web application. It has a few packages that it uses that are custom nuget packages. These packages are deployed to and live within the Azure Organization Feed. Using the YAML below I can Restore, and Build and these packages get “pulled down”. However, when I try to use the publish command, the DLL’s for the nuget packages never make their way to the published website.
YAML:
trigger:
- main
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'x64'
ASPNETCORE_ENVIRONMENT: 'Staging'
steps:
- task: UseDotNet#2
displayName: 'Install .NET Core SDK 5.0.100'
inputs:
version: 5.0.100
performMultiLevelLookup: true
includePreviewVersions: true
- task: DotNetCoreCLI#2
displayName: '.NET Restore Packages'
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'select'
vstsFeed: '9ae2db37-long-private-guid'
- task: DotNetCoreCLI#2
displayName: '.NET Build Projects'
inputs:
command: 'build'
publishWebProjects: False
projects: '**/*.csproj'
arguments: '-c Staging --output $(Build.ArtifactStagingDirectory)'
#I expect that the next section would include DLL from nuget feeds, but it does not.
- task: DotNetCoreCLI#2
displayName: '.NET Publish Staging'
inputs:
publishWebProjects: true
command: 'publish'
feedsToUse: 'select'
vstsFeed: '9ae2db37-long-private-guid'
arguments: '-c Staging --runtime win-x64 --verbosity Detailed --output $(Build.ArtifactStagingDirectory)/Staging'
projects: '**/*.csproj'
zipAfterPublish: false
- task: PublishBuildArtifacts#1
displayName: 'Creating Artifact'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/Staging'
ArtifactName: 'drop'
publishLocation: 'Container'
I did read something about “copytolocal” this solved an issue for me before, but that option is not present in Visual Studio 2019 (Version 16.11.15). If I right click the package there is no way to instruct it.
The only way I have found to get this to work is to create a build task, it pulls the packages, then I publish, but manually copy the DLLs from build that are missing from publish. There HAS to be a better way.
I have this situation ,i trying to build and connect my pipeLine with sonarCloud i have a .net 5.0.x project and .net core 3.1.x , when build the project normally works ok , but when start to add the sonar cloud task starst to fail.
with the next yalm my build is working fine :
trigger:
- qa
- develop
- master
resources:
- repo: self
variables:
tag: '$(Build.BuildId)'
stages:
- stage: Build
displayName: Build image
jobs:
- job: Build
displayName: Build
pool:
vmImage: 'windows-latest'
steps:
- task: UseDotNet#2
displayName: 'Install .NET 5.x.x SDK'
inputs:
version: '5.0.x'
performMultiLevelLookup: true
includePreviewVersions: true # Required for preview versions
- task: UseDotNet#2
displayName: Use Dot Net Core 3.1.x
inputs:
packageType: 'sdk'
version: '3.1.x'
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.sln'
displayName: 'dotnet build'
But when i add SonarCloudPrepare#1 before my build :
trigger:
- qa
- develop
- master
resources:
- repo: self
variables:
tag: '$(Build.BuildId)'
stages:
- stage: Build
displayName: Build image
jobs:
- job: Build
displayName: Build
pool:
vmImage: 'windows-latest'
steps:
- task: UseDotNet#2
displayName: 'Install .NET 5.x.x SDK'
inputs:
version: '5.0.x'
performMultiLevelLookup: true
includePreviewVersions: true # Required for preview versions
- task: UseDotNet#2
displayName: Use Dot Net Core 3.1.x
inputs:
packageType: 'sdk'
version: '3.1.x'
- task: SonarCloudPrepare#1
inputs:
SonarCloud: 'tp-survey'
organization: 'teleperformance-sonarcloud'
scannerMode: 'MSBuild'
projectKey: tp-cm-back-survey
projectName: 'tp-cm-back-survey'
extraProperties: |
sonar.exclusions="**/bin/**/*,**/obj/**/*,**/Migrations/**,**/*.dll"
sonar.coverage.exclusions="test/**"
sonar.cs.roslyn.ignoreIssues=true
sonar.verbose=true
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.sln'
displayName: 'dotnet build'
I getting this error :
Command-line syntax error : 'D:\a\1\s\TPSurveyUnitTest\bin\Debug\.netcoreapp,version=v5.0\TPSurveyUnitTest.dll.RoslynCA.json' is not a valid value for the '/errorlog:' option. The value must be of the form '<file>[,version={1|1.0|2|2.1}]'. [D:\a\1\s\TPSurveyUnitTest\TPSurveyUnitTest.csproj]
181 Warning(s)
1 Error(s)
Why are doing wrong ?
i tried adding the restore task but the same error.
Thanks in advance.
The SonarCloud tasks require .NET Core 2.x to be available in the machine. So your fix will be by adding this task before the SonarCloudPrepare task
- task: UseDotNet#2
displayName: 'Install .Net Core sdk 2.1.x (needed for sonar scanner)'
inputs:
version: 2.1.x
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: 'restore'
projects: '**/*.csproj'
This is mentioned here in the sonarsource community issue.
https://community.sonarsource.com/t/dotnet-core-3-0-dotnet-sonarscanner/14753
Update:
You should also do dotnet restore before running the scanner.
We tried many of the methods that are indicated in the article. The following helped, the following settings were added to the project (.csproj ):
TEST .csproj
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
<OutputPath>..\YourProductPath\bin\Tests\</OutputPath>
MAIN .csproj
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
<OutputPath>..\YourProductPath\bin\Release\</OutputPath>
In the pipeline, change the build from .sln to .csproj
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
projects: '$(Build.SourcesDirectory)/YourProductPath/YourProduct.csproj'
arguments: '--configuration $(BuildConfiguration)'
I have searched around for a while, but not been able to find a good way to create a "installation bundle" for web service to run on IIS.
My problem is that we need to manually copy files to the on premises servers due to security, and thus not allowed to automate this job. But as far as I can see all the IIS Deployment templates uses Deployment group to distribute the releases to registered servers.
Is there a way to create a Release pipeline for IIS that produce a zip file/artifact that can be downloaded manually from DevOps or from a drop folder instead?
I have made one Release pipeline using tasks CopyFiles#2, FileTransform#1 and UniversalPackages#0 to copy the build artifact, transform the appsettings.json file and publish the package, but this does not add the nesessary files for IIS, such as the web.config file.
Thanx for any responses :-)
This is the build pipeline yml file:
trigger:
- release*
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: build
projects: '**/*.sln'
configuration: '$(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'dotnet test'
inputs:
command: test
projects: '**/*Tests.csproj'
arguments: '--configuration $(buildConfiguration) --no-restore --collect "Code coverage"'
testRunTitle: 'Unit and Integrtion Tests'
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: publish
publishWebProjects: true
arguments: '--configuration $(buildConfiguration) --output $(build.artifactStagingDirectory)'
zipAfterPublish: true
- task: PublishPipelineArtifact#1
displayName: 'publish pipeline artifact'
inputs:
targetPath: '$(build.artifactStagingDirectory)'
artifactName: 'WebAPI'
And the Release pipeline:
Release pipeline
You could directly use a release pipeline which associated with a build pipeline.
Add the related build pipeline under Artifacts, also, remember to add the Publish build artifacts Task under the build pipeline, which will help the release catch the final zip folder.
Then, you could create a Release under Stages, use Manage IISWebsite Task and Deploy IIS Webiste/App Task.
That is enough.
After som twists and turns I ended up with this solution, using a template yml file for Dev and Release.
If anyone have any suggestions for improvments, please comment below.
Hope this can be of help :-)
Pipelines:
azure-pipelines-build-template.yml:
variables:
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
artifactPath: '$(build.artifactStagingDirectory)'
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build solution'
inputs:
command: build
projects: '**/*.sln'
configuration: '$(buildConfiguration)'
- task: DotNetCoreCLI#2
displayName: 'dotnet test solution'
inputs:
command: test
projects: '**/*Tests.csproj'
arguments: '--configuration $(buildConfiguration) --no-restore'
testRunTitle: 'Unit and Integrtion Tests'
- task: DotNetCoreCLI#2
displayName: 'dotnet publish to pipeline'
inputs:
command: publish
publishWebProjects: true
arguments: '--configuration $(buildConfiguration) --output $(artifactPath)'
zipAfterPublish: true
- task: PublishPipelineArtifact#1
displayName: 'publish pipeline artifact Flyttavle'
inputs:
targetPath: '$(artifactPath)'
artifactName: 'WebAPI'
azure-pipelines-dev-build.yml:
trigger:
- dev
pool:
vmImage: 'windows-latest'
extends:
template: azure-pipelines-build-template.yml
azure-pipelines-release-build.yml:
trigger:
- release*
pool:
vmImage: 'windows-latest'
extends:
template: azure-pipelines-build-template.yml
Releases:
I have created 4 releases, Azure_Dev_Deploy and Azure_Release_Deploy which deploys to Azure, and On_Prem_Prod_Deploy and On_Prem_Test_Deploy that creates packages to download for on premise deployment.
Dev_Deploy and Release_Deploy:
Difference here are:
Trigger is set up for changes respectively on dev and release branches
Deployment points to the app service in Azure for respectively dev and release app services
Variables points to Variable groups respectively for dev and release variable substitutions (defined in Library)
Release Pipeline and Tasks for Dev_Deploy and Release_Deploy
(same setup for both, but picture shows the Dev deployment)
And the yaml view of the task:
Deploy Azure App Service:
steps:
- task: AzureRmWebAppDeployment#4
displayName: 'Deploy Azure App Service'
inputs:
azureSubscription: '$(Parameters.ConnectedServiceName)'
appType: '$(Parameters.WebAppKind)'
WebAppName: '$(Parameters.WebAppName)'
packageForLinux: '$(System.DefaultWorkingDirectory)/_BEDevBuild/WebAPI.zip'
JSONFiles: '**/appsettings*.json'
On_Prem_Test_Deploy and On_Prem_Prod_Deploy:
Difference here are:
Creates Artifacts respectively for on-prem-test and on-prem-prod
Variables points to Variable groups respectively for on-prem-test and on-prem-prod variable substitutions (defined in Library)
Release Pipeline and Tasks for On_Prem_Test_Deploy and On_Prem_Prod_Deploy
(same setup for both, but picture shows the Test deployment)
And the yaml view of the tasks:
File Transform:
steps:
- task: FileTransform#1
displayName: 'File Transform: on-prem/prod'
inputs:
folderPath: '$(System.ArtifactsDirectory)/_BEReleaseBuild/*.zip'
fileType: json
targetFiles: '**/appsettings*.json'
Universal publish:
steps:
- task: UniversalPackages#0
displayName: 'Universal publish'
inputs:
command: publish
publishDirectory: '$(System.ArtifactsDirectory)/_BEReleaseBuild'
vstsFeedPublish: '********-****-****-****-************/********-****-****-****-************'
vstsFeedPackagePublish: 'on-prem-prod'
packagePublishDescription: 'Package for on premise production'
Download Artifacts:
Then to download the artifacts in the Artifacts feed, I use the following statement from Powershell locally.
PS! As for today it is not possible to download from a REST call for the universal package which ruined my grand plan of creating a download link in the Wiki, but hopefully this will be supported in the future.
on-prem-test:
az artifacts universal download --organization "https://dev.azure.com/[my org name]/" --project "[DevOps project id]" --scope project --feed "on-premise" --name "on-prem-test" --version "*" --path .
on-prem-prod:
az artifacts universal download --organization "https://dev.azure.com/[my org name]/" --project "[DevOps project id]" --scope project --feed "on-premise" --name "on-prem-prod" --version "*" --path .
Tip on parameters:
--version "*" will allways get latest version in the feed for the given package name
--path . downloads the package to where you execute the command in Powershell
I have a solution containing 4 projects (names simplified for clarity)
MyApplication (.Net Standard 2.0)
MyApplication.Test.1 (.Net Core 3.1)
MyApplication.Test.2 (.Net Core 3.1)
MyApplication.Test.3 (.Net Core 3.1)
The solution folder contains the *.sln file, and one folder per project (plus stuff for Git source control).
The three test projects each consume a private NuGet package, "MyNugetPackage"; this package exists on our Azure environment as an artifact. They also use NUnit3 - the test project's NuGet references are as follows:
<PackageReference Include="MyNugetPackage" Version="2020.1.1" />
<PackageReference Include="nunit" Version="3.12.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.16.1">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0" />
I created the following YAML file for our pipeline:
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: release
platform: x64
steps:
- task: NuGetToolInstaller#1
inputs:
versionSpec:
checkLatest: true
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: '{GuidA}/{GuidB}'
- task: MSBuild#1
inputs:
solution: '**/*.sln'
msbuildArchitecture: 'x64'
platform: 'Any CPU'
configuration: 'Release'
msbuildArguments: '-m'
clean: true
- task: DotNetCoreCLI#2
inputs:
command: test
projects: '**/*Tests/*.csproj'
arguments: '--configuration Release'
Initially, this failed at the MSBuild step, until I worked out how to set up the permissions for it to pull from our Azure artifact (the vstsFeed property). Having got the MSBuild step to execute successfully, it then fails when the DonNetCoreCLI (Test) step executes: I get multiple messages similar to:
MyTestFile.cs(13,22): error CS0234: The type or namespace name 'ABC'
does not exist in the namespace 'MyNugetPackage' (are you missing an
assembly reference?)
[d:\a\1\s\MyApplication.Test.1\MyApplication.Test.1.csproj]
I'm assuming that this means the Test projects can't find our private 'MyNugetPackage'. But how could this be when MSBuild succeeded?
I tried swapping the MSBuild step out for a Visual Studio build, but to no avail (again, build step worked, test step failed):
- task: VSBuild#1
inputs:
solution: '**\*.sln'
platform: 'any cpu'
configuration: 'release'
clean: true
maximumCpuCount: true
msbuildArchitecture: 'x64'
I then tried swapping the MSBuild step for the .NET Core build so that it matched the job for the tests
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration Release'
And now the BUILD step failed.
So it seems to me that I have two routes forward:
Either stick with either MSBuild or Visual Studio Build, and work out how to then execute my tests, or
Work out how to compile successfully with DotNetcoreCLI#2 rather than use MSBuild/Visual Studio Build, and hope that the tests will then work as expected
The documentation from Microsoft seemed so simple (Run your tests)....hoping someone can help guide me on the right path.
You can run dotnet test command on your local machine to check if it works fine locally. Make sure you can successfully build and test your projects locally first.
In you pipeline, You can try use vstest task after msbuild task to run the tests.
- task: VSTest#2
inputs:
testAssemblyVer2: |
**\*[Tt]est*.dll
!**\*[Tt]estAdapter*.dll
!**\obj\**
searchFolder: $(system.defaultworkingdirectory)
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
You can also run Dotnet restore task to restore the packages before dotnet test task
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: restore
projects: '**/*.csproj'
feedsToUse: select
vstsFeed: 'nugettest'
So the solution that (eventually) worked for me was to use the .Net Core (DotNetCoreCLI#2) build, and to break every step apart, e.g.
# 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: 'windows-latest'
variables:
buildConfiguration: 'Release'
platform: x64
steps:
- task: DotNetCoreCLI#2
displayName: 'Restore for MyApplication'
inputs:
command: 'restore'
projects: 'MyApplication/*.csproj'
feedsToUse: 'select'
vstsFeed: '{GuidA}/{GuidB}'
- task: DotNetCoreCLI#2
displayName: 'Restore for MyApplication.Test.1'
inputs:
command: 'restore'
projects: 'MyApplication.Test.1/*.csproj'
feedsToUse: 'select'
vstsFeed: '{GuidA}/{GuidB}'
- task: DotNetCoreCLI#2
displayName: 'Restore for MyApplication.Test.2'
inputs:
command: 'restore'
projects: 'MyApplication.Test.2/*.csproj'
feedsToUse: 'select'
vstsFeed: '{GuidA}/{GuidB}'
- task: DotNetCoreCLI#2
displayName: 'Restore for MyApplication.Test.3'
inputs:
command: 'restore'
projects: 'MyApplication.Test.3/*.csproj'
feedsToUse: 'select'
vstsFeed: '{GuidA}/{GuidB}'
- task: DotNetCoreCLI#2
displayName: 'Build MyApplication'
inputs:
command: 'build'
projects: 'MyApplication/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Build Test.1'
inputs:
command: 'build'
projects: 'MyApplication.Test.1/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Build Test.2'
inputs:
command: 'build'
projects: 'MyApplication.Test.2/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Build Test.3'
inputs:
command: 'build'
projects: 'MyApplication.Test.3/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Execute Test.1s'
inputs:
command: 'test'
projects: 'MyApplication.Test.1/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Execute Test.2s'
inputs:
command: 'test'
projects: 'MyApplication.Test.2/*.csproj'
- task: DotNetCoreCLI#2
displayName: 'Execute Test.3s'
inputs:
command: 'test'
projects: 'MyApplication.Test.3/*.csproj'
--Fixed it... Geez this stuff is Janky.
Microsoft link to explain what to do
https://learn.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio
I had to remove the version tag from the Microsoft.AspNetCore.All references in the csproj file.
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" **DELETE Version Version="2.2.0" />
--Edit 12/4
I I installed on my PC .netcore to 2.2, Now it fails the same. I didn't change a setting in my Project. I am specifying in my project settings to use 2.1 not 2.2.
It appears in the YAML where i set the .netcore version is not applying.
- task: DotNetCoreInstaller#0
displayName: 'Use .NET Core Tool Installer'
inputs:
version: 2.1.500
I am not sure what to do now.
--
I get following error when building in azure devops or publish from VS to an Azure app service. Visual Studio builds it fine.
(Restore target) -> 2018-12-04T01:30:44.4900171Z
D:\a\1\s\cbw.services\cbw.mvc.services.csproj : error NU1202: Package
Microsoft.AspNetCore.All 2.2.0 is not compatible with netcoreapp2.1
(.NETCoreApp,Version=v2.1). Package Microsoft.AspNetCore.All 2.2.0
supports: netcoreapp2.2 (.NETCoreApp,Version=v2.2)
My Build YAML
resources:
- repo: self
queue:
name: Hosted VS2017
steps:
- task: DotNetCoreInstaller#0
displayName: 'Use .NET Core Tool Installer'
inputs:
version: 2.1.500
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.9.1'
inputs:
versionSpec: 4.9.1
#- task: NuGetCommand#2
# displayName: 'NuGet restore'
# inputs:
# restoreSolution: '***.sln'
# feedsToUse: config
# nugetConfigPath: 'NuGet.config'
# externalFeedCredentials: <Name of the NuGet service connection>
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: restore
projects: '**/*.sln'
feedsToUse: config
nugetConfigPath: NuGet.config
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '**/*.sln'
arguments: '--configuration $(BuildConfiguration)'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: test
projects: '**/*Tests/*.csproj)'
arguments: '--configuration $(BuildConfiguration)'
#- task: DotNetCoreCLI#2
# displayName: Publish
# inputs:
# command: publish
# publishWebProjects: True
# arguments: 'release --output $(build.artifactstagingdirectory)'
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: 'publish'
publishWebProjects: True
projects: '**/*.sln'
arguments: release -o $(build.artifactStagingDirectory)
zipAfterPublish: True
modifyOutputPath: false
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
- task: AzureRmWebAppDeployment#3
inputs:
azureSubscription: 'Azure CBW Dev'
WebAppName: 'cbwServicesDev'
Package: $(System.artifactstagingdirectory)/**/*.zip
You need to add the .NET Core SDK installer task to your build.
Edit: It needs to be the first task, or at least before any build task.
A good post by Scott Hanselman walks you through this problem.