1

I have done some searching on this topic and am able to find individual solutions to generate custom build numbers as well as patch assembly info, however I am unable to accomplish both. When using a custom POWERSHELL script that I found in a search, I am able to set the build number to what I create with the script, however this build number does not patch. The only success I have in patching is when using set numbers plus a counter. But the number that the POWERSHELL script creates does not persist to an extent that the Assembly patcher can work with. Am I doing it wrong?

tshepang
  • 12,111
  • 21
  • 91
  • 136
DrDoomPDX
  • 282
  • 3
  • 12

2 Answers2

2

In our project, we solved it using a the CommonAssemblyInfo.cs file. Basically add it to your solution, remove the AssemblyInfo.cs files from the individual files and when you compile all dlls will have the assembly info that is specified in the CommonAssemblyInfo.cs file.

We update this file as the first step before we do the compiling. The unique number we use is the changeset id from the source control system (in our case TFS). Basically, the source control change set number is guranteed to be unique and highly relevant. It will tell you exactly which assembly was generated by which changeset in your source control.

Basically the first step in our build configuration is a powershell script that looks something like below (Update path to CommonAssemblyInfo.cs accordingly)

$fileLocation = Join-Path -Path "%teamcity.build.checkoutDir%" -ChildPath "Source\CommonAssemblyInfo.cs" 

$oldValue = "AssemblyVersion\(""(\d+)\.\d+\.\d+\.\d+""\)"
$newValue = 'AssemblyVersion("$1.0.0.%build.vcs.number%")'

(get-content $fileLocation) | foreach-object {$_ -replace $oldValue, $newValue} | set-content $fileLocation

So build setp 1, update your assembly version with the Changeset number as above. Step 2, compile your solution. Step 3 to x, Test, Deploy etc. etc.

Chaitanya
  • 5,203
  • 8
  • 36
  • 61
  • This code seems to get me very close. It is successfully changing the assembly build numbers, however, the final compiled EXE is still showing 1.0.0.0 in its details. But when I look at the working directory of the teamcity checkout folder, the assemblyinfo file is properly adjusted. So this seems to be yet another case of not persisting. – DrDoomPDX Mar 07 '14 at 18:41
  • To clarify, I AM using this code before the compile step. So I am not sure why it is not persisting. In contrast, if I use AssemblyInfo patcher with system counter / build numbers, it seems to do the job fine. The only problem I have with that method is that it does not allow me to customize the build number the way that I want. – DrDoomPDX Mar 07 '14 at 19:43
2

I finally solved it with a little bit of Chaitanya's provided logic... but modified:

$ww = ([Math]::Floor([DateTime]::Now.DayOfYear/7)+1)

Write-Host "##teamcity[buildNumber '%major.minor%.$ww.%build.counter%']"
$fileLocation = Join-Path -Path "%teamcity.build.checkoutDir%" -ChildPath "\SourceDir\AssemblyInfo.cs" 

$oldValue = "AssemblyFileVersion\(""(\d+)\.\d+\.\d+\.\d+""\)"
$newValue = [string]::Concat("AssemblyFileVersion(""%major.minor%.", $ww, ".%build.counter%", """)")

(get-content $fileLocation) | foreach-object {$_ -replace $oldValue, $newValue} | set-content $fileLocation
DrDoomPDX
  • 282
  • 3
  • 12