Right now our assemblies have a version number like 2.0.831.0. As I understand it, that's major version, minor version, date and build number. If I make a change and build again on the same day it's 2.0.831.1, 2.0.831.2 etc.
My TeamCity build number format is simply 2.{0} where {0} is an auto incremented number that just goes on forever (2.195, 2.196 etc).
How do I make TeamCity look exactly like the assembly version? We want to be able to associate the Change Log with the assembly version so anyone can say assembly version 2.0.831.2 had these changes in these files.
Extra info: Our build step uses the "Visual Studio (sln)" option instead of "MSBuild" if that matters. We use Subversion for source control if that matters. Our TeamCity version is 6.5.1 (build 17834).
I would recommend you to adopt the semantic versioning scheme {major}.{minor}.{patch}
and append a 4th element for the build number {major}.{minor}.{patch}.{build}
.
This is way more useful as to include the build date into the versioning scheme.
TeamCity 6.5 (you haven't specified a version) has a build feature which could be used to patch the version in the AssemblyInfo.cs during the build. See the documentation for the AssemblyInfo Patcher.
You could then define the build number format in the way you would like to have in your assembly and use the format for the build itself, as also for the patching feature.
One solution is to use the MSBuild runner, and write an MSBuild script which reads the version information from the AssemblyInfo file, sets the TeamCity build version to that value whilst running the build, then increments the build number part of that version, and writes the value back to the AssemblyInfo.
This isn't particularly trivial, as you need to have an understanding of writing custom MSBuild scripts, and you will likely need to use some of the community tasks etc to read/write the version information.
We also use the concept of a global AssemblyInfo file, which all of our assemblies reference (using Add Link in VS), and thus we only need to update the one file during the build.
There is an excellent article here, which describes doing common CI tasks with MSBuild. He is using CruiseControl.NET, but much of it still applies. If you are running TeamCity 6.5 though, I would look into using its build features exclusively, as this will be much easier to maintain than a custom MSBuild script.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With