Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
In some projects, I use the AssemblyInfo Patcher build feature to modify the AssemblyInfo.cs’s version information. Mainly I was just using a static version with the %build_number% suffixed at the end. Something like 1.2.3.%build_number%. However, I decided to go with a date version number of YYYY.MM.DD.%build_number%
Variables
The first thing that caused me an issue was there is no existing system or environment variables defined that provide you with date parts. I figured this by adding a new build step for creating an environment variable using Service Messages.Service messages are specially constructed pieces of text that are used to pass commands/information about the build from the build script to the TeamCity server. To be processed by TeamCity, they need to be written to the standard output stream of the build, i.e. printed or echoed from a build step. It is recommended to output a single service message per line (i.e. divide messages with newline symbol(s))What this allowed me to do was create a build step in PowerShell and use Write-Host to output a service message:
Write-Host "##teamcity[setParameter name='env.BUILD_DATE' value='$([DateTime]::Now.Year.ToString() + "." + [DateTime]::Now.Month.ToString() + "." + [DateTime]::Now.Day.ToString())']"This will create a new environment variable that I can use called
%env.BUILD_DATE%
AssemblyInfo Patcher
As mentioned, I use this build feature to modify the AssemblyInfo.cs, however, I immediately ran into an issue.AssemblyInfo Patcher should be used with the automatic checkout only: after this build feature is configured, it will run before the first build step. TeamCity will first perform replacement in the files found in the build checkout directory and then run your build.The issue is that the AssemblyInfo patcher is run before the first build step which is setting the environment variable. Meaning I cannot use the environment variable in the AssemblyInfo patcher.
Snapshot Dependencies
What I decided to do was create a new build configuration that only contained one build step. That build step would be the PowerShell above which sets the environment variable. Then I would link my existing build configuration to this new build configuration. In TeamCity these are defined as SnapShot Dependencies.Build configurations linked by a snapshot dependency will use the same snapshot of the sources. The build of this configuration will run after all the dependencies are built. If necessary, the dependencies will be triggered automatically.
Dependency Properties
Once I had my dependencies defined, you can use build parameters from linked dependencies. Now in the assembly patcher, I can use the environment variable by:%dep.[ConfigurationID].env.BUILD_DATE%
