Once I had my dependencies defined, you can use build parameters from linked dependencies. If necessary, the dependencies will be triggered automatically. The build of this configuration will run after all the dependencies are built. In TeamCity these are defined as SnapShot Dependencies.īuild configurations linked by a snapshot dependency will use the same snapshot of the sources. Then I would link my existing build configuration to this new build configuration. That build step would be the PowerShell above which sets the environment variable. What I decided to do was create a new build configuration that only contained one build step. Meaning I cannot use the environment variable in the AssemblyInfo patcher. To be processed by TeamCity, they need to be written to the standard output stream of the build, that is printed or echoed from a build step. The issue is that the AssemblyInfo patcher is run before the first build step which is setting the environment variable. Service messages are specially constructed pieces of text that pass commands/information about the build from the build script to the TeamCity server. This will create a new environment variable that I can use called %env.BUILD_DATE% AssemblyInfo PatcherĪs mentioned, I use this build feature to modify the AssemblyInfo.cs, however, I immediately ran into an issue.ĪssemblyInfo 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. What this allowed me to do was create a build step in PowerShell and use Write-Host to output a service message: printed or echoed from a build step. It is recommended to output a single service message per line (i.e. To be processed by TeamCity, they need to be written to the standard output stream of the build, i.e. 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. I figured this by adding a new build step for creating an environment variable using Service Messages. The first thing that caused me an issue was there is no existing system or environment variables defined that provide you with date parts. However, I decided to go with a date version number of YYYY.MM.DD.%build_number% Variables Mainly I was just using a static version with the %build_number% suffixed at the end. Service messages are specially constructed pieces of text that pass commands/information about the build from the build script to the TeamCity server. In some projects, I use the AssemblyInfo Patcher build feature to modify the AssemblyInfo.cs’s version information. 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.

Teamcity service messages