I am new to CICD, Azure DevOps. I am trying to implement CICD to Asp .Net Web API project using Azure Devops. I saw few videos on internet and started implementing it. I am done with some standerd CI part but the build is always failing because of one project in a source solution.
So Is there any way to exclude a project from build?
I haven't written .yml file by myself it is auto generated by Azure Devops.
Actually I need a way to exclude a file from .yml file from azure buil pipeline. I tried the following code but still Test.cs is included in build.
trigger:
batch: true
branches:
include:
- master
- QA
paths:
exclude:
- Test/Test.cs
Basically, you can pass the ExcludeFoldersFromDeployment as a parameter to MSBuild. Combining that with the SkipExtraFilesOnServer does the trick.
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevWebServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_TestSite
/p:IgnoreDeployManagedRuntimeVersion=True
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
OR
Use an MS Build project file.
Create an MSBuild project file from scratch
And the at the build solution step in VSTS, select or type the project file path instead of the solution file. You will have to remove it down the road though. The maintenance tasks tend to be hard and counter-intuitive whenever the code base grows quickly. Visual Studio will not warn you if you have build errors (like obsolete path) in the MS Build project file.
Related
We are using azure devops for CI/CD, but we got a problem with our build pipelines.
When creating visual studio build, we would like to get the specific folder where the build is created, so we can copy the folder (add outputpath parameter to visual studio task doesn't work with some projects).
The main problem is, that name of the project and the repo can be different.
We would need something like:
$(agent.builddirectory)\s\PROJECT-NAME\bin\Release
Is there a way to get the project name or the output folder?
$(agent.builddirectory) isn't working.
EDIT: We need to use the build pipelines at this point, so currently we don't work with artifacts or release pipelines (we know we should...)
It seems like you are using Azure Pipelines to do what MSBuild / dotnet cli are made to help you.
You can instead use msbuild / dotnet cli to build and pack your project output to a designated location, like output in the repository root folder, that is common across all projects that use the pipeline.
If you only checkout 1 repository, all tasks will be executed in the repository folder. You do not need to mess with $(agent.builddirectory)\s\xxxx. Accessing output is as simple as output/ in your pipeline.
I'm trying to create a pipeline in Azure DevOps and I get compilation errors caused by a missing reference:
[warning]C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5):
Warning MSB3245: Could not resolve this reference. Could not locate
the assembly "ABC". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
I have a VS2017 solution with 2 projects.
ABC which is the actual application
ABC.UnitTests where I added some unit tests (I'm using MSTest)
When I build the solution locally, I'm able to do a successful build with the following steps:
Build ABC project => ABC.dll is generated
Add reference in ABC.UnitTests proj to ABC.dll
Build the entire solution => build successful
The .cs file in ABC.UnitTests references the application in this way, and generates the warning above:
using ABC;
If I do a clean build where ABC.dll is deleted and then I do a build of the entire solution I get the same MSB3245 warning. So the issue is reproducible locally if the dll does not exist.
Then, when I upload the solution to Azure DevOps, I do the following steps.
Upload the solution from local VS2017 and a project is created in Azure
Build the project in Azure DevOps => reference issue reported
I have a YAML config file with name azure-pipelines.yml which references the hosted 2017 agent.
pool: vmImage: 'vs2017-win2016'
Alternate flow:
Upload the solution from local VS2017 and a project is created in Azure
Comment out the reference to ABC.UnitTests project from the sln file
Create the pipeline => build successful.
You shouldn't refer any DLL as you mentioned in the comment.
The proper way is to refer to as a project. This way the DLL takes care of itself during the build
Proper way is
References -> (Right Click) Add References -> From that using Projects tab you can choose the Project which is generating that DLL(assemblies)
You can refer this SO
I'm having some issues deploying an Azure WebJob using Visual Studio Team Services (VSTS).
The WebJob seems to be deployed successfully but it breaks the Azure website that is hosted in the same App Service! I don't have this problem if I deploy using VS2013.
This is my build task that generates the WebJob deployment package:
And this is my deployment task:
There are no errors when I deploy the Azure WebJob. If I go to the Azure Portal I see the WebJob is there, and it runs successfully. WebJob files are copied into the wwwroot\App_Data\jobs\triggered\RemoveExpiredDids folder as expected, but the problem is that some other files will be copied into the wwwroot\App_Data\bin folder, which will break the existing website that was already deployed into that App Service!!!
So I decided to find out why this was happening. After downloading and extracting the deployment package I saw there are 2 folders (app_data and bin) and the scheduler file (settings.job):
This explains why some assemblies are coppied into the wwwroot\App_Data\bin of the App Service. The strange thing is that this doesn't happen when deploying from VS2013!!! I took a look into the MSBuild log and found the following line:
Object dirPath ([app service name]\bin) skipped due to skip directive 'SkipBinFolderOnDeploy'.
Concluding, bin folder is included when deploying the Azure WebJob from VSTS but is excluded when deploying it from VS2013.
So my question is: how to prevent the bin folder from being deployed when using VSTS? Is there any MSBuild parameter/flag to do this?
I've had issue with this particular problem as well.
The latest method I found is using Web Deploy Operation Settings , -skip:Directory= (in this case it would be -skip:Directory='\\bin') when you create your azure deploy task in the release definition (Additional arguments). I've seen that this indeed excludes the bin folder from the update actions (result).
Let me know if this helps you in any way.
Refer to these ways to deploy webjob to azure:
Modify Visual Studio Build task to deploy webjob with FileSystem (MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish)
Add Delete Files task to release definition to delete bin folder (Source Folder: $(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob); Contents:bin)
Modify Azure App Service Deploy task (1. Uncheck Publish using Web Deploy option. 2. Package or folder: $(System.DefaultWorkingDirectory)/[artifact name] /drop/WebJob)
I was finally able to fix it, thanks #starain-MSFT for pointing me in the right direction. I had to make some minor changes, though. This is the task that creates the deployment package:
MSBuild arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:Configuration=$(BuildConfiguration) /p:OutputPath=.\bin\ /p:publishUrl="$(build.artifactstagingdirectory)\temp\WebJob"
The difference here comparing to #starain-MSFT answer is that I had to add the /p:OutputPath= parameter, otherwise I'd get the following error:
The OutputPath property is not set for project
After generating the package, I delete the bin folder and zip it (this reduces the build time).
This is my deployment task:
Please note that $(DeploymentPackagePath) is the path to the zip file that contains the deployment package, as mentioned before. It doesn't matter if you deploy the package as a zip file or if you unzip it and deploy the folder, it works both ways.
I am trying to set up continuous integration on my server using Visual Studio online.
Created a new agent pool.
Installed and configured a new build agent that I added to that agent pool.
Then I trigger a new build of my code to be handled in my agent pool.
I manage to build it but how to set up the task "Copy and publish build artifacts".
My goal here is to just copy the final website files e.g. binaries, images, cshtml, but NOT all files such c# files. Well sort of like the "Right-click > publish" operation in visual studio.
What value do I need to enter in "Copy root" field? (please see image below)
The documentation is located at: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables
It all boils down to what the output path for your binaries is. If you're not overriding it via an MSBuild argument, $(Build.SourcesDirectory) with a value of **\bin\* will probably get you what you're after.
For a web application, make sure you're building with appropriate MSbuild arguments (something along the lines of /p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true should do the trick). This will get you a _PublishedWebsites folder in $(Build.StagingDirectory).
Then all you need to do is publish Copy Root of $(Build.StagingDirectory) and Contents of **\_PublishedWebsites\*
Keep in mind that Publish Build Artifacts means publish build artifacts to VSTS or a file share, not deploy build artifacts to a web server
I've been using Jenkins/Hudson CI for deploying my .NET web site project. I've been using the MSbuild plugin to build my project, and then xcopy to copy it out to the server.
I've noticed if I use the publish feature in Visual Studio I get a different set of files. I've got the config transforms working, but I end up with all the .cs files and a winmerge compare shows the binaries being different.
So, I'd like to either get Jenkins working just like the publish feature, or confirm that an xcopy deploy is functionally the same thing.
I've had good experiences with using Web Deploy and as a final build step with Jenkins running a bat file containing:
msdeploy.exe -verb:sync -source:package=%PACKAGE% -dest:auto,ComputerName=%TARGETHOST%
You'll have to install the web deploy package on your build server and the extention on IIS.
I'm using the MSBuild Jenkins plugin to build and then deploy the project. As mentioned in other answers, you need to have Web Deploy installed.
In the project configuration page in Jenkins, you need to add the following to the Command Line Arguments field:
/p:Configuration=Debug /p:DeployOnBuild=true /p:PublishProfile=publishProfileName
Of course, you need to first create the publish profile, either in VS or by exporting it from IIS and you also need to specify the solution file path in the MSBuild Build File field.