Is this possible to build only a single project and its dependencies specified in a pipeline script?
If I have a Visual Studio Solution with multiple projects, and websites, and I want to build and publish only a specific website and it's dependencies, how could it be done when using DevOps Pipelines, so it does not build the whole solution, but only the required projects for that specific website.
If you want to only build a single project in your solution, you could use the MSBuild task in Azure Devops Pipelines and then point it to the project you want to build.
Another way would be to in your VS solution to edit the Configuration Properties. In the Configuration Manager you can create a Configuration called Single_Project or something like that and then in the properties select which projects to build when using that configuration. Then when you use the VS Build task and specify the configuration you created for your build.
Related
Is MSBuild being deprecated in favor of TFS/Azure DevOps Build pipelines? I have some custom build steps I need to add, such as obfuscating code and computing file hashes. I'm not sure if I should add them as a custom target in my MSBuild/csproj file or if they should be separate steps in a build pipeline. Has Microsoft provided any guidance about which one to use and/or are there common best practices used by the .NET community?
What are the pros/cons of doing custom build steps in MSBuild vs as a build pipeline step?
No, it's not deprecated. Build pipelines are just glorified task runners. All those pipelines do is run your MSBuild script; they don't actually "build" anything in the same sense that MSBuild builds things.
That said, here are some scenarios where it makes sense to add additional build targets and conditions to an MSBuild file:
It needs to happen during local development
It needs to happen across multiple CI solutions (i.e. Jenkins, TeamCity, Azure DevOps)
You foresee switching to a different CI solution in the future
That should make the pros of MSBuild pretty obvious. It's going to work anywhere you build your application, including on your local desktop, and it's going to be portable. It also has the advantage of being automatically tracked by version control, which (unless you're using YAML build), Azure DevOps builds are not.
Is there any similar plugin like this
https://wiki.jenkins.io/display/JENKINS/Config+File+Provider+Plugin
in TFS Build & Release
I want to provide configuration.json file which is not included in git source.
Unfortunately, there is no such extension in TFS/VSTS Build & Release.
According to your tag tfs2013, seems you are working with XAML build.
Just like you need a workspace on your dev machine to develop your app, you must specify the workspace that the build agent uses to build and test your app. Then we get/pull source files from TFS server side. It's not able to achieve below similar features in TFS UI:
Adds the ability to provide configuration files (i.e., settings.xml
for maven, XML, groovy, custom files, etc.) loaded through the Jenkins
UI which will be copied to the job's workspace.
As a workaround, you could try to put configuration.json files in a ftp server instead of git source and then use a PowerShell solution to down the files in build agent workspace. If create a PowerShell to over FTP you can have it called by the build template(customize workflow).
We have just installed TFS 2015 (Update 1) on-premise and are trying to create a Continuous Integration/Build system using the new TFS Build system. The build works fine, and gives me a green light, but when I look at the default build it has only built the binaries from the bin directory, and there seems to be no easy way to deploy the app on-premise to a local server.
There are two deploy options for a filesystem copy, and a powershell script, and it would certainly be easy enough to use them to copy files to a new server, but since the build only built the binaries, I don't see a tool to gather up the Web artifacts (cshtml, images, scripts, css, etc..) for this.
After an exhaustive google search, I've only found one article which talks about this at:
http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/
However, this uses WebDeploy and creates a rather messy deploy package.
How can I deploy the site (standard MVC web application, in fact my tests are using the default boilerplate site created by the create project wizard) complete with artifacts to a local server in the easiest possible way? I don't want to have to install WebDeploy on the servers, and would rather use PowerShell or something to deploy the final artifacts.
The build is just the standard Visual Studio build template, with 4 steps (Build, Test, Index & Publish, Publish Build Artifacts).
We use "Visual Studio Build" step and as Arguments for MSBuild we use following line:
/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration)
On Variables tab page DeploymentConfiguration has to be configured. It must be the Name of the publish Profile (filename of the pubxml file). If the file Name is Build.pubxml the publish profile is Build.
for example:
/p:DeployOnBuild=True /p:PublishProfile=Build
I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager.
His msbuild arguments look like this:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website
The difference between this and the accepted answer is that this parameter set stages everything in an artifacts folder, and then saves it as part of the build. We can then deploy exactly the same code repeatedly.
We capture the web.env.config files alongside the for-deploy folder and then use xdt transforms in the release process to ensure everything gets updated for whichever environment we're deploying to. It works well for all our web projects.
We use WebDeploy/MSDeploy for 40+ applications and love it. We do install WebDeploy on all our servers so we can deploy more easily but you could also use the Web Deploy On Demand feature which doesn't require WebDeploy be pre-installed.
I have Microsoft TFS build process to deploy web project to azure web role, this occurs automated way every day. I have followed Azure article https://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-continuous-delivery/
I have following MSBuild arguments in my build process, as above article suggested
/t:Publish /p:PublishDir=C:\MSCD\
When i add database project to my project solution, build is keep failing. Getting error message
The "SqlPublishTask" task was not given a value for the required
parameter "SqlPublishProfilePath"
When i publish my web project, i don't want database project to be published. How to drop DACPAC file to drop folder ? so i can use powershell to update my database in azure.
I am using TFS 2012 On-Premise. Could someone give suggestion on how to solve this problem?
You need to create Master-child build definitions and in master build definition configure solution with build and deploy disabled in configuration manager .and in child build configure database project alone .
Create Master and child build definition such that they share common drop .
#Siva palla's answer solved this exact same issue for me. Here are the complete set of changes we made to get this working.
Changes in Visual Studio
Originally I was using a single configuration called 'Deployment' that was set to deploy both our WinForms project and our SQL project (VisionShellWin is the WinForms project, the two Vision.SQLMigration projects are the SSDT projects) so everything below is based on changes to Deployment. For most people you'll have Release instead of Deployment, all of the below should still work fine, just substitute in Release for Deployment:
To separate that single configuration in two I created a new configuration:
I set that new deployment to copy its settings from the old Deployment configuration and not to create new configurations for each of the projects (the existing project level Deployment ones are fine):
In that new deployment I then unticked the boxes to Build and Deploy the database projects:
I then did the exact same thing again to create a Database specific deployment:
And in that one I unticked everything except the database files:
That's everything needed in Visual Studio, so I committed all of that and synced it back to DevOps.
Changes in Azure DevOps
In DevOps I cloned my existing Visual Studio Build stage (called 'Build Winforms solution') and renamed the clone to Build Databases:
I added two new build variables in the Variables tab, named ClickOnceBuildStageConfiguration and DatabasesBuildStageConfiguration with their values set to the names of the new configurations we just created in VS:
And then I changed the WinForms build stage to use the new ClickOnceBuildStageConfiguration variable - note that we still have the /T:"VisionShellWin" /target:Publish MSBuild Arguments needed for ClickOnce set:
And the new Build Databases stage to use the databases variable - note that we don't have any MSBuild Arguments:
Finally, in addition to the copy stage I already had for copying the ClickOnce application files into the drop artifact:
I also added a Copy Files stage (called 'Copy Dacpacs') to copy the DacPac into the drop too:
Once you've done all of that, you should end up with a build that works and an artifact that contains both the ClickOnce files and the DacPacs
How do I or can I, create a hierarchy of build definitions in TFS 2012?
I currently have a master build script (.cmd) that calls multiple child scripts (.cmd).
I want to migrate this to the TFS build system and maintain the hierarchy.
I can't seem to figure out if this is possible using the TFS 2012 build system.
Here's what I'm talking about:
MasterBuildScript.cmd
call componentscript1
call componentscript2
call componentscript3
call ...
call packaging routine for all components
componentscript1.cmd
build solution componenta1
build solution componenta2
build solution componenta3
...
componentscript2.cmd
build solution componentb1
build solution componentb2
build solution componentb3
...
more components...
Is there a way to do this with the standard TFS 2012 Build Definitions?
- Bruce
There is a way to do this without doing any custom coding. You will have to make a minor addition to a build process template, however. That doesn't use code, it uses Windows Workflow Foundation.
Essentially, you would need to setup TFS Team Build definitions for each .cmd build script that you currently have. One for the master build, one for each component build. The real work involved here is converting your .cmd script into a TFS build definition.
Then, to auto queue the "child" builds, you can edit the process template for your master build definition and add an "InvokeProcess" activity - this lets you shell out to the command line as part of the build process. You can use the command line utility TFSBuild.exe to kick off the "child" builds. http://msdn.microsoft.com/en-us/library/aa337622(v=vs.90).aspx
I've used something similar in the past where I have a build for my core set of assemblies. That build then kicks off all of the builds which have dependencies on those assemblies.