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 ag
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.