blog.fossmo.net

I understand that Microsoft uses this template when versioning their products: Major.Minor.Build.Revision. Major is changed when the "developers" want to show that there is a big change in the software and backward compatibility cannot be assumed. Maybe a major rewrite of the code is done. Minor number represents a significant enhancement with the intention of backward compatibility. Build number is a small change, for example a recompilation of the same source. Revision is used to fix a security hole and should be fully interchangeable. Both Build and Revision are optional. This information is based on MSDN Version Class.

The way I version most projects is the same way that Microsoft does, but I increase the Build and Revision each time I build the project. The build number is created this way: MMdd. MM is number of months since the project started and dd is the rest in days. A project started yesterday (25.09.2008) will have this build number to day: 0001. Revision is created this way: HHmm. HH is the hour of the day, and mm is the minute of the hour. It will for example show like this: 1302.
Major and Minor is used much the same as Microsoft suggests. A beta product will have a zero as the Major number.
I often use MSBuild as the build scripting language and I have created a MSBuild task for increasing the build number and revision. It can be downloaded from the link below.

To use it you have to add these lines to your MSBuild file:

<UsingTask TaskName="TFTasks.TFBuildNumber" 

    AssemblyFile="$(MSBuildStartupDirectory)\tools\treefrog.tasks\TFTasks.dll"/>

<UsingTask TaskName="TFTasks.TFRevisionNumber" 

    AssemblyFile="$(MSBuildStartupDirectory)\tools\treefrog.tasks\TFTasks.dll"/> 

And use the task by doing something like this:

<TFBuildNumber StartDate="09.09.08">

  <Output TaskParameter="BuildNum" PropertyName="buildNumber"/>

</TFBuildNumber>

<TFRevisionNumber>

  <Output TaskParameter="RevisionNum" PropertyName="revisionNumber"/>

</TFRevisionNumber> 

You can then update your AssemblyInfo file by doing something like this:

<Target Name="SetVersionInfo" DependsOnTargets="SetTimeStamp" >

  <Attrib Files="@(AssemblyInfoFiles)" Normal="true" />

  <FileUpdate Files="@(AssemblyInfoFiles)"

     Regex="AssemblyFileVersion\(".*"\)\]"

     ReplacementText="AssemblyFileVersion("

     $(Major).$(Minor).$(buildNumber).$(revisionNumber)")]" />

</Target> 

To get this running, you also need to use the MSBuild Community Tasks. It can be downloaded from tigris.

I posted a question on StackOverflow and asked how people version their projects.
The answers can be found here.

How do you version your projects?

TFTasks-1.0.0927.0.zip (2.48 kb)

Tags: msbuild, continuous integration

I have used Cruise Control from ThoughtWorks at my CI server for a long time. CC.NET is a very good tool, but you have to spend a lot of time messing around with XML and tasks. It's time consuming. I have heard a lot of positive things about TeamCity from Jetbrains, so I figured that I wanted to try it. And, yes Jetbrains is the same company that makes ReSharper. A wonderful tool. I started out installing TeamCity on my server, and everything went like a breeze. I had my test project up and running within 10 minutes. Very easy configuration due to the web GUI. All good, BUT MY TESTS DID NOT RUN! I searched the Internet and could not find a good answer to why the tests did not run. I finally started to look at my build file, and it turns out that I imported my MSBuild community tasks this way:

This makes TeamCity very sad, and it won't display the test results. What TeamCity accepts is this:

So, the tip is: stay away from importing your tasks by using <UsingTask> tag, and rather use <Import>.

Tags: teamcity; continuous integration

Stack Overflow is a programming Q & A site that's free. I have used it for about 14 days now, and I find it very useful. For every question you ask, or answer, you earn badges. This makes it kind of cool to ask questions and answer questions on this site. The questions and answers can be voted for, and this way bad answers (or questions) are ranked low and good answers are ranked high. I really think this site will take off. The people behind the site is Jeff Atwood and Joel Spolsky, the first mentioned, being one of my favorit bloggers. They also run a podcast. It can be found at blog.stackoverflow.com. Check out the Stack overflow site at www.stackoverflow.com

Tags: stackoverflow

Ncover is no longer free, and if you want to use code coverage in your build scripts, without paying for it, you need to find another solutions. In my case, this solution is partcover. It works pretty much like Ncover do (did) and you can include it in your MSbuild scripts to cover unit tests. Partcover uses some COM stuff and needs to be registered (you can of course install the msi on every computer you run partcover on and the problem is solved). I prefer that all the tools I use together with my build scripts, work without me installing anything. Adding the target shown below to your MSbuild script will make it possible to use partcover without installing it.

What it does is to register the PartCover.CorDriver.dll before partcover is run, and unregister it after partcover is run.

To run this script you need to run under administrator privileges.

Tags: partcover buildscripts