Im using the tf.exe and I need to know the actual Revision ID on my Team foundation server.
I tried tf history, but I simply need the latest revision.
I am using TFS 2010 and Visual Studio 2008.
An Environment Variable would do it for me.
You don't need to use the tf.exe, if you are using vNext build (TFS 2015 and later version), you can directly use the predefined variable Build.SourceVersion to get the latest version value (changeset ID) in current build. See Predefined variables for details.
Then you can set the build number format with the variable Build.SourceVersion:
e.g : $(TeamProject)_$(BuildDefinitionName)_$(Build.SourceVersion)_$(Date:yyyyMMdd)$(Rev:.r)
But note that the variable $(Build.SourceVersion) in build number format is only available when builds were triggered automatically on commit/checkin (on Continuous integration). It can not be resolved when you queue build manually and keep the Source Version field as empty (by default it will get the latest version). So, if you queue build manually, then you need to specify the specific Source Version (e.g C458) in the queue build dialog. See my reply in another thread : Using SourceVersion and rev:r in TFS2015 build names
Another workaround is getting the latest changeset with the variable Build.SourceVersion first and then upgrade the build number automatically within the build process.
TFS 2010 means XAML builds, so you need to use the IBuildDetail.SourceGetVersion property.
The simplest way is to assign a variable just before the UpdateBuildNumber activity; the variable value is computed mixing the build number computed by TFS and the above property.
Related
I am currently upgrading our XAML build definitions to the new build system. Already squashed a few errors, but now I am at a point where I can no longer tell what could be wrong. We use PowerShell scripts for most of the build process, and although all required data is available on the server, I get the following error when running the build:
Does anyone have any idea what could cause that error? Or at least where I should check?
Thanks in advance.
EDIT:
The script prepares build configuration that can not be done by external tools and are specific to our project. The error happens on the line $teamProjectCollection =...
Function Get-BuildNumberFromUri() {
<#
.SYNOPSIS
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.DESCRIPTION
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.NOTES
May fail if $env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI or $env:BUILD_BUILDURI
are not set
#>
[String] $CollectionUrl = "$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI"
[String] $BuildUrl = "$env:BUILD_BUILDURI"
if (-not $CollectionUrl -or -not $BuildUrl) {
return "0"
}
[void[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.VersionControl.Client")
$teamProjectCollection = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrl)
$buildServer = $teamProjectCollection.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
$buildDetail = $buildServer.GetBuild($BuildUrl)
$buildNumber = $buildDetail.BuildNumber
return $buildNumber
}
Here's the problem:
You're using a new build system. You need to step back and re-evaluate the existing scripts you have in context of the capabilities of the new build system.
You have this big PowerShell snippet that retrieves the build number. That's awesome, except for two things:
It's never going to work -- the SOAP object model does not have any awareness of "new" (e.g. non-XAML) builds. There is a REST API for them, instead.
You can retrieve the current build number by looking at the $env:BUILD_BUILDNUMBER variable. No special code necessary.
In previous versions of Team Foundation Server the Client Object Model was registered in the GAC and pre-loaded by the build agent when running XAML. In the new agent the build steps are independent of the client object model.
You have two options to locate the Client Object Model assemblies:
Ship the Client object model with the powershell scripts by referencing the Client Object Model Nuget package.
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.Client
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.ExtendedClient
Detect the location where Visual Studio is installed and loading the client object model from the Team Explorer extension folder. Examples can be found on the docs wiki.
There is also an easier, but officially unsupported option:
Do not use $(Agent.ServerOMDirectory). It is not safe for task authors to depend on the SDK bundled with the agent. Agent.ServerOMDirectory is a convenience variable that points to the latest SDK bundled with the agent. The SDK may have breaking interface changes between different versions. Depending on the latest version shipped with the agent will cause your task to be unreliable.
Getting at the buildnumber
There is a build variable being populated to set the build number in your script it can be referenced using $env:Build.BuildNumber.
To set the build number write a special statement to the console using
$value = "$($env:Build.BuildNumber)_US`
Write-Host "##vso[build.updatebuildnumber]$Value"
Alternatively you can use my Set Variable task from the VSTS Variable Toolbox extension.
I'd like to be able to trigger a build in TFS Build when a developer tags in Subversion. I'd also like to use the tag number as part of the build and release name. Is this possible in TFS right now?
There is no this built-in trigger for building a repository type of subversion in TFS.
You could first get the event (a developer create a tag in svn) from SVN. Not sure how to do this in SVN, should be something like the service hooks in TFS. Then trigger a build in TFS 2017 using REST API. How to do this please refer: How to trigger a build in TFS 2015 using REST API
As for how to use the tag number as part of the build and release name, see below:
Create custom build number during build
With Team Build you can update the build number at any time during the
build by outputing "##vso[build.updatebuildnumber]1.2.3.4" to the log
during the build.
You can see the full list of logging commands here https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
This will update the build number & name.
The down side that you have run into is that you can no longer use the
auto-incrementing number that you have been trying to use. You need to
come up with the version number yourself, and then pass it back using
the output above.
Source
Add two more related blogs:
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
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 have my automated builds working but I want to be able to go back to a specifc labeled version and build from that source. The build definition under "Process" has the item "Get Version" but this is for a specific changeset which seems fairly useless. Does anyone have any idea how I would go about doing this?
The Get Version accepts what TFS calls an versionspec which can be either a changeset or a label. To specify a label just prefix it with an L.
LMyLabel
#Dylan Smith: Is right. You can specify in the advanced Get Version parameter the label by: LmyLabel or CmyChangeset in order to queue a specific version. There are other options like date, "W" (Version last fetched to your workspace), or "T" (latest version) as well.
For more information: Building a Specific Version with Team Build 2008
During your build process, label the code (In my case I use the build number as part of the label).
Then when you want to build a specific labeled version, pass the label to the build script, get the code from the library by label, build the code, and deploy.
See http://msdn.microsoft.com/en-us/library/fx7sdeyf.aspx for how to get a labeled version.
i have a nightly build in my TFS server that runs every night and is working completely fine. we plan to create a clickonce application as well which is currently working fine except the publish version (ApplicationVersion) which we want to automatically increment with each build instead of entering it manually. An important point to mention is that we only want the Revision part to be increment by 1 with each build. e.g 1.1.1.1 for first time and 1.1.1.2 for the next build.
Please note as alot of information is available for assembly versioning so i am not at all interested in it, i just want my application version to increment so please do point me in this direction.
My VS and TFS server is 2008.Is there any way i can edit my Publish version before build as i do in this case to edit the InstallUrl of the projecte-g
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<InstallUrl>(.*?)</InstallUrl>"
NewValue="<InstallUrl>$(InstallUrl)</InstallUrl>" Force="true"/>
The publish version is a combination of
<ApplicationVersion>
and
<ApplicationRevision>
and in my scenerio it is defined as follows
<ApplicationRevision>1</ApplicationRevision>
<ApplicationVersion>1.9.4.%2a</ApplicationVersion>
and then
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<ApplicationRevision>(.*?)</ApplicationRevision>"
NewValue="<ApplicationRevision>$(ApplicationRevision)</ApplicationRevision>" Force="true"/>
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<ApplicationVersion>(.*?)</ApplicationVersion>"
NewValue="<ApplicationVersion>$(ApplicationVersion)</ApplicationVersion>" Force="true"/>
But the value is never incremented after first run. after the first run the value is always 1.9.4.1. Is there any way that it should be incremented for the next Build. Have tried application revision with *+1, #+1 ...
You should update your TFS server to TFS 2012 first. This will maintain support for VS2008 (TFS 2013 no longer supports it) and gives you access to community tools that no longer support 2008.
You will find two custom activities in the TFS Community Build Extensions that will do what you need.
ClickOnce - this updates and configures the manifests for clickonce deployments from build
TfsVersion - this creates and populates the versions number with the correct incrementing
No, I do not know any what to do this (except to roll you own) in TFS 2008. It is just too old to be supported by the community.