Our build process changes the version number of all AssemlyInfo.cs files, so that the version number can be managed completely by the build server.
Right now, we commit the changed AssemblyInfo.cs files after successful build. During evaluation of TeamCity, I couldn't find a way to do that without using svn via command line.
Because TeamCity provides lots of settings related to the version control (e.g. management of login credentials, labeling), I wonder why there is no option like "checkin changes after build" or something like that.
So, is it good practice to commit updated assemblyinfo.cs files after the build on the build server? What are the pros and cons?
Best Answer
One of the big risks with letting your build server commit changes to your version control is that it is very easy to create an unintended feedback loop.
It is often desirable that a commit to (trunk of) the version control automatically triggers a build on the build server. However, if the build server itself also commits changes, then it would be continuously triggering itself.
As normally the build server only changes build-related metadata (build date, version number, etc.), the common solution is to let the build server generate the file with that information before starting the actual build process.
If the file contains additional information apart from what the build server can generate, the version control system can contain a template for
AssemblyInfo.cswhere the build server just has to replace/fill in the correct version/build information. For local builds, you can add a pre-build step to fill in the template with build information that identifies the build as a local build.Using such a template file, the static and manually changed content of AssemblyInfo.cs is nicely version controlled, but you don't get endless revision changes on that file for every run of the build system.