I am talking about this:
The documentation I found is here - https://learn.microsoft.com/en-us/azure/devops/pipelines/process/parameters?view=vsts, but I must be plain stupid, because I do not understand one bit of it.
I do not know why it is so hard, but I cannot find anything meaningful on the web.
We have an on-premises TFS.
Let's say you have a build configuration ("Release") that you want to use in conjunction with multiple instances of the Visual Studio Build task.
You could add a variable called BuildConfiguration and then put the value $(BuildConfiguration) in the "Configuration" box for all of your Visual Studio Build tasks.
Or, you could enter the actual value, "Release", and then link the Configuration field in Visual Studio build to a pipeline parameter. Then you can manage the value from the "Pipeline" view.
Related
I am trying to clickonce-publish a client app compiled using the scriptable build system available on Visual Studio Online. It seems something new.
I was able to find some articles showing how to customize msbuild and add parameters to make it work on local TFS:
http://publicvoidlife.blogspot.pt/2014/05/continuous-integration-with-tfs-and.html?showComment=1441022327672 and
http://www.dontpaniclabs.com/blog/post/2011/04/29/clickonce-publish-and-deploy-from-team-foundation-server-2010/
But in Visual Studio Online there are some different things. I see there are some "build steps" I can set that include package/deploy scripts. Can I use them for clickonce?
If setting clickonce publish during msbuild is the way to go, how to set parameters on the "visual studio build" script?
I don't know how to specify the "publish" option on msbuild script ui nor how to specify necessary parameters.
Any ideas?
Thank you,
Just as described in the blogs you posted, you need to customize build process template to be able to publish clickonce app. Here is another link which is useful for you, from which you can check the detailed information on how to do the customization step by step (includes information on how to add arguments, how to add /t:publish msbuild arguments) (it is written for TFS2010, applies to VSO as well): http://www.codeproject.com/Articles/122388/TFS-Team-Build-with-ClickOnce-Applications
The default build template for TFS has a format of $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
This translates to something like BuildName_20141111.1 for the first build of the day, BuildName_20141111.2 for the second and so on that.
That's all well and good but what I'd like to do is pull out that .r and insert it into the assembly before it's compiled by the build server.
I've already edited the build template to update the various AssemblyInfo.cs files and such and that's working fine. Right now we are toying with the idea of Major.Minor.yyDDD (Day of year).r but the catch is that very last part - how do we get $(Rev:.r) from within a build template?
I've tried looking through the various environmental variables and I can pull out the entire Build definition string (i.e. BuildName_20141111.1) but really all I want is that .1 (or more specifically "1"). Is there a way to do this programmatically? Is there an environment variable I've missed? Or is there a way that I can actually access things like $(Rev:.r) directly?
I am relatively new to TFS but this is the last hurdle before I can move a lot of projects to it.
You effectively need to parse this off yourself from the BuildName parameter. If you are using TFS 2013 you can do it in PowerShell. Prior versions need a customized build template.
There are prebuilt solutions to this. Best is the TfsVersion activity or the VersionAssemblies.ps1 that is provided as part of the TFS Community Build Tools.
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information
I setup my build definition, is that all I do when it comes to setting up my build using the Team Explorer GUI?
It seems like the only thing for me to do now is edit the msbuild .proj file?
Is there a GUI for this or its all hand editing from here on it?
Currently there is no MSBuild editor inside Visual studio, but I've read that there gonna be one in Visual Studio Team System 2010 (one based on Workflow Foundation renderer).
If you really want a GUI you could try Microsoft Build Sidekick v2 but it is not free (55$) and not very useful in my opinion.
In TFS 2008 some of the information about a build can be edited through the GUI, but not much. If you right click on the build definition and choose Edit Build Definition you can change the workspace mappings, retention policy, drop location, and triggers. To change anything else you need to edit the .proj file.
What is it that you're trying to do? If you ask a specific question you might get interesting answers.