4

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?

Improve this question
7
  • What part of the version number is updated? Commented Sep 27, 2016 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. Commented Sep 27, 2016 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. Commented Sep 28, 2016 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. Commented Sep 28, 2016 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. Commented Sep 29, 2016 at 6:49

1 Answer 1

Reset to default
6

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.

Improve this answer
4
  • 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. Commented Sep 27, 2016 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. Commented Sep 27, 2016 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. Commented Sep 27, 2016 at 9:15
  • Yes, that is the only difference. Thanks for your opinion, that is also my point of view. Commented Sep 27, 2016 at 9:27

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.