TFS Release Management and GlobalAssemblyInfo

0
votes

My Visual Studio Solution has a GlobalAssemblyInfo.cs to assign version info to the binaries etc...

The build number I use for example is 3.4.* which means 3 is the major version, 4 is the minor version and the wildcard gives me an automated build and iteration number.

My Test environments can have multiple versions of my application deployed at any one time.

This was controlled manually in the past by appending the major and minor version numbers to the application pool name and web application names, e.g.

  • ApplicationPool_3_2
  • ApplicationPool_3_3
  • ApplicationPool_3_4
  • ....

I'm attempting to get all of this into TFS Release Management and have got my build working and firing a release which creates the application pool and web application etc... But I can't work out how to get the major and minor version numbers into TFS Release Management so that I can name the application pool and web application correctly.

I'm using Visual Studio 2013.4, TFS 2013.4 and Release Management 2013.4. All of which are on premise.

2
visual-studio-2013tfsrelease-managementms-release-management
My first thought is that this feels like a dysfunction. Are you attempting to do continuous delivery? If so then the idea is that one build passes through each stage of your pipeline in sequence where it is subjected to some sort of testing - automated, manual, whatever is required for that stage. If a build fails that stage it is deemed void and progresses no further. My blog post series here has a blow-by-blow account of how to set all this up, including one way to automate versioning all the assemblies. - Graham Smith
Thanks for your comments, I agree it is a little dysfunctional, but that's the nature of my product. Its a fat client exposed to users via an aging citrix platform. There are plans in place to replace this, but they're a year out. In the mean time I've inherited a manual release process where web.config files are manually edited between phases and regression testing takes three weeks followed by a week of UAT. We've got a long way to go before we can reach CI Nirvana. - Jason
@Jason Are you restricted from upgrading TFS? The new build/release system in 2015 can get you there, I think. - Sumo
Sumo, thanks for your feedback. We upgraded to 2015 last year and are currently running 2015.1 with our builds integrated to Octopus Deploy. This has solved all of our current internal release problems for this product. Very excited to see Release Management in TFS is coming along so strongly. However, I'm waiting on TFS 2016 before re-visiting TFS Release Management. - Jason

2 Answers

0
votes

You can create major and minor version numbers by adding variables in Variables tab of Build Definition. Then use these variables for Version Number by adding ‘Version .NET Assemblies’ build step like AssemblyVersion("$(VersionMain).$(VersionSub1).$(VersionSub2).$(VersionSub3)"), AssemblyFileVersion("$(VersionMain).$(VersionSub1).$(VersionSub2).$(VersionSub3)")

0
votes

I ended up writing a powershell script and calling that at the start of my build :-

$splitbuildNumber = $env:BUILD_BUILDNUMBER.Split(".")
$ApplicationVersionMajor = $splitbuildNumber[0]
$ApplicationVersionMinor = $splitbuildNumber[1]
$ApplicationVersionBuild = $splitbuildNumber[2]
$ApplicationVersionRevision = $splitbuildNumber[3]

Write-Host “##vso[task.setvariable variable=ApplicationVersionMajor]$ApplicationVersionMajor”
Write-Host “##vso[task.setvariable variable=ApplicationVersionMinor]$ApplicationVersionMinor”
Write-Host “##vso[task.setvariable variable=ApplicationVersionBuild]$ApplicationVersionBuild”
Write-Host “##vso[task.setvariable variable=ApplicationVersionRevision]$ApplicationVersionRevision”`