CODEWITHSUNDEEP
c#.netsvnversion-controlmerge
Andy
Andy

Reputation: 11502

Version control and updating of AssemblyInfo files

I'm maintaining an application of (mostly) C# code using subversion. I'm wondering what is the best practice for when and where to update the AssemblyInfo.cs files to reflect the version number of the product as it ships.

Let's say I have a trunk, and some maintenance branches for previous versions and tags to tag each release when it happens.

If I update the AssemblyInfo files in the branch or trunk before tagging (this is my current approach), it means I can look down the log of that branch to see when releases happened which is quite useful, but it gives me spurious merge conflicts when merging between branches. For instance say I make a bug fix in the version 4 branch which updates version 4.7 to 4.8; when I try to merge that fix into the version 5 branch, the AssemblyInfo is bound to conflict.

I have also considered updating the AssemblyInfo files in the tag itself. this avoids the merge conflict problem but means you can't see the releases when looking down the history of trunk or a maintenance branch, and it also seems to violate the principle that a tag should be read-only.

From what I gather, some people like to update the AssemblyInfo files on-the-fly during the build process, and not store them in SVN at all. Although on the face of it, it seems like a good idea to automate the version numbering, I think I'd feel a lot more comfortable if the AssemblyInfo files are checked in immediately prior to performing the build so that there is a direct correlation between the version number on the assembly and the source it came from.

Upvotes: 2

Views: 1923

Answers (1)

oleksii
oleksii

Reputation: 35925

Just sharing experience: I do this on the build server only in the automated fashion. I've configured it once and not touching it any more, apart from infrequently incrementing major and minor version. Here is an outline:

  • AssemblyInfo.cs is committed to source control
  • AssemblyInfo.cs is not manually changed by developers
  • Build server picks up source on any change to source control
  • Build server changes AssemblyInfo automatically
  • Build server produces artefacts with correct version
  • When I tag/branch I create a tag with the build version from Build Server

Modern build servers will have features that will automate the whole process of changing this file, for example see AssemblyInfo patcher in TeamCity

The version strategy I use is:

major.minor.build_number.svn_revision_number

Where major and minor are manually hardcoded as configuration parameter on the build server. build_number is automatically incremented by the build server. svn_revision_number is picked up from the svn commit number.

Upvotes: 1

Related Questions