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?

  • What part of the version number is updated? Sep 27 '16 at 8:30
  • The build number is automatically updated. However, the whole version number is managed in teamcity, so minor, major and patch numbers are incremented manually and updated during the build.
    – JanDotNet
    Sep 27 '16 at 8:40
  • 1
    Independently from your main question: instead of letting your build process change numerous AssemblyInfo.cs files, why not keep the version number in one separated class as const values, and refer from any other AssemblyInfo.cs to that class? Yes that works, we do exactly this here for a VS solution with around 60 projects.
    – Doc Brown
    Sep 28 '16 at 6:16
  • Because a) that requires to increment the build version manually for each build and b) teamcity provides a feature that sets the version automatically for all assembly info class so there is no additional effort.
    – JanDotNet
    Sep 28 '16 at 7:40
  • @JanDotNet: having a short look into the TeamCity manual, it seems you have both options, replacing the build number in each AssemblyInfo.cs as well as to make an arbitrary replace in an arbitrary file.
    – Doc Brown
    Sep 29 '16 at 6:49

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.cs where 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.

  • Thanks for the answer. The first point is valid... I'll check the default behavior - however teamcity supports special options to avoid that (e.g. do not run VSC trigger if the commit has been done by the build user). So that is not a real problem so far.
    – JanDotNet
    Sep 27 '16 at 8:51
  • The second point describes exactly how the update of the assembly info works. The template can be just an assembly info file with any version number - teamcity will replace that version number automatically. The question is: is it better to commit the changes done by the build server, so that the source control represents exactly the state of the create binaries or not.
    – JanDotNet
    Sep 27 '16 at 8:56
  • 2
    @JanDotNet: If the difference between the state in source control and the state used to build the binaries is just a version number, then in my opinion the difference is not worth an additional commit to the version control system. Sep 27 '16 at 9:15
  • Yes, that is the only difference. Thanks for your opinion, that is also my point of view.
    – JanDotNet
    Sep 27 '16 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.