Should AssemblyInfo.cs be placed in version control?

Question

I have an automated build system using CruiseControl. I am using the SvnRevisionLabeller to to get the version string to use. With this string I can use nant to update AssemblyI

Answer 1

Either don't version AssemblyInfo.cs at all, or put "developer version" of them into the repository and have CruiseControl.Net svn-revert them after build (I do the later so that builds made on developers workstations are easily extinguishable from the "official" ones downloaded from CruiseControl.Net).

As for reproducing the same build labels later - you already have to do the rebuild by calling MSBuild / NAnt by hand, simply pass to it CCNetLabel set to appropriate value and you'll get the same assembly versions generated as with the build invoked from CruiseControl.Net (MSBuild: /p:CCNetLabel=1.4.2.333 , NAnt: -D:CCNetLabel=1.4.2.333).

Answer 2

I use a CommonAssemblyInfo.cs file which I add a link to in every project.

The only attribute I have in this file is AssemblyFileVersion and have CC.Net / Msbuild update the version every build.

Make sure any project that includes CommonAssemblyInfo.cs doesn't have duplicate attributes in AssemblyInfo.cs.

If you check out the CC.Net source code you'll see that is how they have they're build configured.

Answer 3

I always have it checked in. In fact I believe this is the default behavior with Team System Source Control.

Answer 4

We have a MSBuild script that generates all the needed AssemblyInfo.cs files prior to the build. This way I can also use the SVN revision number in the assembly versions. The AssemblyInfo.cs files are not checked into SVN (they're ignored so that they don't bother people) but generated prior to building (doesn't matter whether it an automated build script or from VS).

I also supply a batch file to take care of the AssemblyInfo.cs files generation so that the developers don't need to bother with the details.