The last three days I have been back in Wellington, NZ, working with the rest of the development team at Intilecta. We are currently in a transition period between the end of Version 1, which we officially signed off last week, and the commencement of Version 2. Like most development schedules there are always odd jobs that get postponed. In our case it is really about maturing our development process and tools.
For version 1 we were using SourceSafe (and praying to the MS gods that it would survive) primarily because the whole team was based in the Wellington office. Now that the team has spread out physically using SourceSafe has just proven too frustrating due to the way it checks code in/out. Anyhow the first task in refactoring our development tools has been to ditch SourceSafe and to wheel in Subversion. I must admit I have been extremely impressed with TortoiseSVN (integration into File Explorer – including Vista) and Ankh (integration into VS2005 – although doesn’t use standard API it does a great job).
The next step in the process is to upgrade our build process. Up until now we have quite successfully been using CruiseControl.NET, although I must admit we have had to put a number of cludges in to get auto product versioning and correct labelling both within SourceSafe and CC.NET. Again I have been pleasantly surprised with the latest version of cc.net and in particular the way that it integrates with Subversion. What we want to be able to do is for the daily build we want the revision from Subversion (assigned whenever someone checks code in) to be the final digit in our product assembly version numbers (eg <major>.<minor>.<build>.<subversion revision>). We also want this version number to be the label that appears in CC.NET.
To achieve the first part we use a command line utility that comes with TortoiseSVN called SubWCRev which allows us to take a template file (eg assemblyinfo.template), replace appropriate keywords (in this case $WCREV$) with subversion information (in this case the latest subversion revision number) and generate a file that can be built as part of the build (in this case assemblyinfo.vb). All our projects simply reference this file to ensure they all have the same assembly version number.
The second part was a little more tricky, or so we thought. Initially we thought we would have to do all the processing to retrieve the revision number and to implement a labeller that works with cc.net. A bit of searching revealed that others had tried to achieve the same result and in fact the latest version appeared to have a new labeller called the lastChangeLabeller. At least the documentation in the current stable release (v1.2.7) seemed to imply that it was included. In actual fact it is only included in one of the intermediary builds (we are using 1.3.0.2728). With this labeller in place cc.net is reporting the version of our product (as defined by the assembly version number).
I would be interested to hear what others have done in terms of automating the versioning of assemblies as part of the build process.