Workflow for continuous integration and automatic version stamping: .NET projects + CC.NET + SVN + MSBuild

Question

I'm using SVN + CruiseControl.NET + MSBuild to build .NET projects. These are the technology specifics so that you understand the environment and my terminology, but the question is more general in nature.

Right now, my CI workflow is pretty simple:

1. CC.NET detects new revision to the project trunk detected in SVN
2. CC.NET working copy is updated from SVN
3. MSBuild is launched against a .proj file at the trunk
4. Unit tests run
5. If successful, project is copied/deployed

At step 3, I would like to "stamp" the version number onto the build; in my case, in the AssemblyInfo.cs file, most likely using something like the AssemblyInfo task from msbuildtasks. As well, I would like to be able to repeat that build at that specific version number. Right now, I'm thinking that probably after step 4, I'll need to commit/tag back to SVN the project with the stamped AssemblyInfo.cs, but I'm having trouble thinking about the most straightforward way to do this.

If I'm committing the project with the stamped AssemblyInfo.cs file back to the repository, it cannot be to the trunk since that will trigger another automated build: infinite loop. So, I would assume that it would need to go to a new tag. So then I would tag the revision, switch the working copy over to the tag, commit, then switch back to trunk. Is that the common way?

Or am I over-complicating this? Should I even be worrying about committing this build back to the repo or just ZIPping up the built project and storing in a structured location in the file system?

Answer 1

In my current and previous company. we stamp/modify the assemblyInfo.cs during build and commit back the assemblyInfo files after every successfull build.

To prevent infinite loop; we exclude the asssemblyInfo.cs from triggering build in the ccnet config.

The drawback: whenever we click the force button, new version will be committed back to trunk repository even though no modification in source code.

I am still researching for better ways to versioning the assemblyInfo :)

added 2 hrs later:

After some researching; instead of commiting the assemblyInfo back to trunk; some people create a tag of working directory(with the modified assemblyInfo ) CCNET does support this mechanism: SVN TagOnSuccess working copy and updated AssemblyInfo.cs

Jeremy Miller use this approach http://codebetter.com/jeremymiller/2007/12/06/do-you-really-know-where-that-code-has-been/

drawback: there will be a lot of tags

Answer 2

You don't need a msbuild task for version stamping. CCNET will do this for you. msbuildtasks style task is just for TFS where this isn't built in.

There is no reason to worry about checking in the assemblyinfo file. As long as there is a label (or whatever svn calls them) you are fine.

As far as rerunning an exact copy of the build, I'd say just zip them up and store the ones that actually are used. You don't need to store every build.

What I have always done is have a CI build which is run on every checkin plus a release build that is only run manually for deployments. The CI build doesn't get a version number at all, nor is it stored anywhere. The versioned build gets a version number and is saved.