I would like to fully automate my current application deployment process.
I have big project in Azure DevOps. Code was writen on C# for .Net core.
The Solution consists 3 sites and 2 windows service application (build to msi file).
When I was creating Pipelines and choose "Azure Repos Git" and click on my project then in Configure your pipeline choose "ASP.NET CORE".
On "Review your pipeline YAML" I have a problems.
How can I in YAML file point to the site I want to build?
How can I in YAML file point to the site I want to build?
When you use the Asp.net Core Yaml template, it will use the dotnet build script to build your project. You could add the target path to the dotnet build command.
For example:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build **/*.csproj --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
On the other hand, I recommand you to use the task to run the build.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration $(BuildConfiguration)'
You could add the specific path is in the projects field.
Here is a doc about DotNetCoreCLI task and Task introduction.
Related
I'm attempting to set up an Azure DevOps build pipeline against a .NET Framework 4.7.2 solution which contains a Visual Studio Installer Project. I've set up a self-hosted agent on a Windows Server 2019 VM, which has Visual Studio 2019 Community installed. The build pipeline contains the NuGet Installer task, followed by the NuGet task, set up to restore the referenced NuGet Packages. Below is the YAML snippet:
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '$(solution)'
Running a build with this configuration however, results in the following error in the build logs:
[error]The nuget command failed with exit code(1) and error(C:\##############.vdproj(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.)
This appears to be due to a performance enhancement that's been made in newer versions of nuget.exe. The suggestion, based on this GitHub issue, is to enable skipping non-existent package targets using the RestoreUseSkipNonexistentTargets MSBuild setting.
The GitHub issue mentions using the NUGET_RESTORE_MSBUILD_ARGS NuGet CLI environment variable in order to set this property, but I don't know how this can be achieved through the NuGet build task.
Since NuGet is now integrated with MSBuild, I then attempted to set this property to false through a command-line argument on the NuGet task. I modified the YAML, setting the command to custom in order to pass arguments. I based the syntax off of the MSBuild restore documentation. It now looks like follows:
- task: NuGetCommand#2
inputs:
command: 'custom'
arguments: 'restore "$(solution)" -p:RestoreUseSkipNonexistentTargets=false'
This build configuration results in the following error:
[error]The nuget command failed with exit code(1) and error(Unknown option: '-p:RestoreUseSkipNonexistentTargets=false')
My question is, how do I go about getting the NuGet restore task to skip package restore on .vdproj projects?
EDIT
The other project in the solution is a C# WinForms .NET Framework project. We're using packages.config rather than PackageReference.
As for your original issue: MSB4025
As you mentioned above, it's one open issue here. Anyone interested at it can track the issue there.
[error]The nuget command failed with exit code(1) and error(Unknown
option: '-p:RestoreUseSkipNonexistentTargets=false')
The nuget restore command won't recognize a msbuild property. See similar issue and more details here.
Since The other project in the solution is a C# WinForms .NET Framework project. We're using packages.config rather than PackageReference.
A workaround for this is to use nuget custom command like this:
- task: NuGetCommand#2
inputs:
command: 'custom'
arguments: 'restore YourProjectName\packages.config -PackagesDirectory $(Build.SourcesDirectory)\packages'
This can skip the restore step for the installer project.
In general you do not need to called nuget restore explicitly anymore. MSBuild does it automatically as part of the build (so you're likely doing it twice). You can add the p:RestoreUseSkipNonexistentTargets=false property to the MSBuild arguments of a VSBuild task or a DotNet build or publish task:
- task: DotNetCoreCLI#2
displayName: Build/Publish
inputs:
command: 'publish'
publishWebProjects: false
projects: '$(solution)'
arguments: '-r $(runtimeIdentifier) /p:RestoreUseSkipNonexistentTargets=false'
zipAfterPublish: false
modifyOutputPath: false
The best way i found :
use 3 tasks on the pipeline tested on vs2022 hosted image
All the tasks uses the Visual Studio 2022 Developer PowerShell.
Task 1 - restore nuget with ignoring the error of the unsupported vdproj
Task 2 - Build the solution with msbuild will not build the vdproj
Task 3 - Build the vdproj only using DevEnv
- task: PowerShell#2
displayName: "restore nuget"
inputs:
targetType: 'inline'
script: |
& 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\Launch-VsDevShell.ps1'
msbuild -t:restore .\<solution>.sln -p:RestoreUseSkipNonexistentTargets=false
ignoreLASTEXITCODE: true
pwsh: true
- task: PowerShell#2
displayName: "build solution"
inputs:
targetType: 'inline'
script: |
& 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\Launch-VsDevShell.ps1'
msbuild .\<solution>.sln
pwsh: true
- task: PowerShell#2
displayName: "create install "
inputs:
targetType: 'inline'
script: |
& 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\Launch-VsDevShell.ps1'
devenv ".\<project>.vdproj" /Build
pwsh: true
I seriously need help to create my yml build file because I cannot find any good tutorial, sample or other king of help anywhere. I always get similar error: See the warning, it seems my build artifact is always empty. All step are succes but I cannot deploy because my files are not found. Stupid.
##[section]Starting: PublishBuildArtifacts
==============================================================================
Task : Publish Build Artifacts
Description : Publish build artifacts to Azure Pipelines/TFS or a file share
Version : 1.142.2
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=708390)
==============================================================================
##[warning]Directory '/home/vsts/work/1/a' is empty. Nothing will be added to build artifact 'drop'.
##[section]Finishing: PublishBuildArtifacts
Here is my pipeline definition
# 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-16.04'
variables:
buildConfiguration: 'Release'
steps:
# - script: dotnet build --configuration $(buildConfiguration)
# displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreInstaller#0
inputs:
version: '2.2.202' # replace this value with the version that you need for your project
- script: dotnet restore
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration Release' # Update this to match your need
- task: PublishBuildArtifacts#1
inputs:
ArtifactName: 'drop'
Note the 2 line I commented
# - script: dotnet build --configuration $(buildConfiguration)
# displayName: 'dotnet build $(buildConfiguration)'
are in fact part of the default script. I'm not using the default script. I'm following the tutorial https://learn.microsoft.com/en-us/azure/devops/pipelines/languages/dotnet-core?view=azure-devops
Also why I cannot use the templates available for my other projects. Is it because I'm using DevOps repository or because my project has specific settings? I have other project I can manage the build then deployment with graphical template and task. A lot more easier.
Yes, help on yaml pipelines seem a bit scattered and thin on the ground at the moment.
Since your project is AspNetCore, I think what you're missing is the dotnet publish task, after the build task and before the PublishArtifacts:
- task: DotNetCoreCLI#2
inputs:
command: publish
publishWebProjects: True
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: True
But here are steps I have been through trying to resolve frustration with netcore yaml pipelines:
You have already looked through the guide's example tasks & snippets at
Build, test, and deploy .NET Core apps ?
You have noticed that you can click on the build log to see the detailed output of each step in your pipeline?
You have noted that the task DotNetCoreCLI#2 is equivalent to running dotnet <command> on your own desktop so you can to some extent run/debug these tasks locally?
I found Predefined Variables gave some helpful clues. For instance it tells us that the path \agent\_work\1\a is probably the $(Build.ArtifactStagingDirectory) variable, so that helped me in mimicking the pipeline on my local machine.
Logically, your error message tells us that $(Build.ArtifactStagingDirectory) is empty when the pipeline reaches the last step. The dotnetcore example page suggests to me that publish is the task that populates it for a web project. For anything else, I think just the dotnet build task is enough.
Just replace in variables:
**/Dockerfile
…by
$(Build.SourcesDirectory)/Dockerfile
That works for me.
I'm trying to set up my build pipeline in azure devops (using azure-pipelines.yml) but I'm unable to set it up correctly. I want the pipeline to build the SQLPROJ (SSDT) project, which is done fine (it produces a dll and I need a dacpac, but that's another story), but my real problem here is that I cannot configure it to copy this .dll/.dacpac to the $(Build.ArtifactStagingDirectory).
I tried several things, here are two of them that didn't work. It seems to me it ignores the msbuildArgs.
- task: MSBuild#1
displayName: 'Build AlmaDb - $(buildConfiguration)'
inputs:
solution: 'AlmaDb/AlmaDb.sqlproj'
configuration: $(buildConfiguration)
msbuildArgs: '/p:OutDir=$(Build.ArtifactStagingDirectory)'
I tried with these, but still no luck:
msbuildArgs: '/p:PackageLocation=$(Build.ArtifactStagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true'
Did anyone else face this problem?
I'm developing a project using asp.net core, Entity framework code first, am trying to run EF migrations as a release step, i was advised to use migrate.exe, yet as far as i knew ef asp.net core doesn't generate migrate.exe file.
Am currently using the below command in the release step. After adding the ef core project's bin folder to the generated artifacts.
Command:
dotnet exec
--runtimeconfig ./HOST.runtimeconfig.json
--depsfile ./HOST.deps.json Microsoft.EntityFrameworkCore.Design.dll
--assembly ./DB_CONTEXT_DLL.dll
--startup-assembly ./HOST.dll --data-dir ./
--root-namespace DB_CONTEXT_NAMESPACE
--verbose database update --context DB_CONTEXT_CLASS -e development
The command step fails with the error:
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'd:\a\r1\a{Publish articats folder}\drop\EF\bin\release\netcoreapp1.1\'.
Am not sure what is the hostpolicy.dll and how to generate it as it isn't generated in the bin folder for the EF core project
Any advice?
You can do Entity framework migration during the deploy process. Simple steps:
Create a publish profile (e.g. Web Deploy package, right click project=>Publish)
General deploy package through Visual Studio Build task with /p:DeployOnBuild=true /p:PublishProfile=[profilename];DesktopBuildPackageLocation="$(build.artifactstagingdirectory)\WebAppCoreEF.zip" arguments
Add deploy task (e.g. Azure App Service Deploy) to deploy this package (You can do it in release)
I have a Visual Studio Online build definition that seems to be misbehaving, but I'm not sure if I've just misconfigured something.
There is a build step which is configured as follows:
Type: Visual Studio Build
Solution: **\mysolutionfile.sln
MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"
The build runs successfully, and the build log shows the msbuild command is executed as follows:
"C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe" "C:\a\1\s\Code\mysolutionfile.sln" /nologo /nr:false /dl:CentralLogger,(more removed for brevity) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="C:\a\1\a" /p:platform="any cpu" /p:configuration="release" /p:VisualStudioVersion="14.0" /p:_MSDeployUserAgent="VSTS_6efdabeb-1c75-43a7-96b2-f40e19a68a35_build_14_122"
As you can see, the package location is correctly set: /p:PackageLocation="C:\a\1\a"
However, later in the build log, the package step shows this log entry:
2017-01-20T05:07:30.9771422Z Executing command ["C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\buildguest\AppData\Local\Temp\PublishTemp\obj\mysolution55\SourceManifest.xml' -dest:package='C:\a\1\s\Code\mysolutionfile\bin\Release\MSDeployPackage\mysolutionfile.zip' -verb:sync -replace:match='C:\\Users\\buildguest\\AppData\\Local\\Temp\\PublishTemp\\mysolutionfile55\\',replace='website\' -retryAttempts:20 -disablerule:BackupRule]
As you can see, in this case the package is being sent to -dest:package='C:\a\1\s\Code\mysolutionfile\bin\Release\MSDeployPackage\mysolutionfile.zip' - and this is indeed where the zip file ends up.
As far as I can tell, this looks wrong. I want to have the packaged application binaries and files end up in the staging directory, but msbuild is overriding me somewhere and putting them into the source checkout folder.
In case it's relevant, the solution contains two projects: an ASP.NET Core web app that is targeting the full .NET Framework; and a portable class library.
Am I doing something wrong in the build configuration?
I reproduced your issue in my TFS Environment and I got the same result with. The package under the "C:\a\1\s" folder not "C:\a\1\a'.
As a workaround, you could add a Copy files step to copy the package from the source folder to $(build.stagingDirectory) path.
I guess that it did not work as you expected because the variable name should be Build.ArtifactStagingDirectory instead of build.stagingDirectory
Example:
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:Configuration=Release /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.ArtifactStagingDirectory)"'
#msbuildArgs: '/T:"MyProject1" /p:OutDir=$(Build.ArtifactStagingDirectory) /nowarn:FS0049'
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: MyWebSiteArtefactZIP
There is also another way to Deploy:
If you have created a Publish Profile (you can use Visual Studio for that),
it is also possible to Publish directly from MSBuild, you can put the Web App username/password in the Azure DevOps Pipeline variables and use them:
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:Configuration=Release /P:DeployOnBuild=true /P:PublishProfile="MyPublishProfile.pubxml" /P:Username=$(username);Password=$(password)'