TeamCity – Ben Hall's Blog

xUnit TeamCity Integration

Last night I was doing some experiments with xUnit and TeamCity. TeamCity has a nice UI for reporting tests, however by default it only supports NUnit. Luckily, extending this to support other tests is easy as it just listens for MSBuild outputs in the right format (##teamcity[testStarted name=’Test1′]).

This worked and my tests where appearing in the report.

On the other side of the ocean, Brad was actually working on extending the existing xUnit MSBuild runner for TeamCity integration.

The advantage of Brad’s runner is that you don’t need to edit your MSBuild script, as long as your using the xunit msbuild task it will know when TeamCity executed the build and log to the correct place. Otherwise, it will log to the standard MSBuild output – very cool!

If you want to use this today, download the source code from CodePlex and build it yourself (Get3rdParty.cmd is a great script to run before you build), but I suggest you wait for the next release (1.0.0.4), where support will be included.

Documentation on how to use the MSBuild task can be found here, as I mentioned, using it via TeamCity is no difference.

Technorati Tags: xUnit, TeamCity

Continuous Integration Builds for CodePlex Projects

As many of you might be aware, I maintain the IronEditor project on CodePlex. I like CodePlex, I find the wiki and issue tracking to be useful, but I find the directory structure and searchablity of projects on the site to be most useful. However, the one thing which I wish it could offer, and this goes for Google Project Hosting as well, is a continuous integration server. I would like to know that after I have pushed my changes to CodePlex, that it does actually compile.

As I’ve posted before, I run TeamCity on my home machine as it is free and easy to configure. As TeamCity can connect to Team Foundation Server (what CodePlex runs under the covers), I decided I would just be able to connect to the CodePlex servers and threat it like any normal source control system.

Sadly, I was wrong. When I tried to connect, I found the following (extremely helpful) error:

If anyone knows the reason why this failed, please leave a comment.

However, all is not lost! CodePlex have created the SVNBridge, a small application which runs on your local machine, or in this case your CC server. This translates all SVN commands into TFS commands, the result is that you can connect to CodePlex using SVN clients, one of which is TeamCity!

Connecting TeamCity via SVNBridge to CodePlex

SVNBridge is a single executable. It lives in the system tray and listens for communications on a particular port, in my case 8081.

In order to connect to SVNBridge, and as such your CodePlex project you must use a particular URL. The URL is your SVNBridgeAddress/YourCodePlexServer/YourProject

For example, IronEditor lives on tfs03.codeplex.com and in order for me to connect via the bridge my URL would be:

http://localhost:8081/tfs03.codeplex.com/IronEditor

With my setup, I simple wanted to be able to click run and TeamCity go off, download the latest code from TFS, build my solution and execute my unit tests again just to be sure I haven’t broken anything (or in my case simply forgot to upload the latest code changes).

In order to connect TeamCity to CodePlex, you simply need to use the Subversion VCS settings and point it at your SVNBridge. Below, are my settings for IronEditor. The username and password you need to use to connect are your website login details.

On TeamCity’s dashboard, I now have my new CodePlex build along with my local IronEditor build, both run the IronEditor.build MSBuild script, they just pull the sources from different locations. After I have pushed my changes to CodePlex, I manually click run, and off it goes. The reason I don’t have it manually checking is because it’s rare I push changes to codeplex and as such I’m happy to be in control of when it happens.

TeamCity is now happily talking to my CodePlex repository, building as and when asked. If you happen to have a spare server, or a windows home server, then you could run this setup from there, have it automatically check for modifications with all the developers on your project benefiting.

Technorati Tags: CodePlex, TeamCity, IronEditor, MSBuild

MSBuild – Build Visual Studio 2008 solution and execute Unit Tests

Previously, I have spoke about how you can update your AssemblyInfo file using MSBuild. However, I haven’t spoken about the very basics – how to build a Visual Studio solution and execute your unit tests.

MSBuild is a very interesting build scripting language, out of the box it includes a set of standard tasks which you can use based on your requirements, such as creating a directory or copying a file in order to correctly build your project. I also take advantage of the MSBuild community task project, while it hasn’t been updated in a while, the tasks work perfectly.

Below is the basic MSBuild script.

DefaultTargets=”Test” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>



        <MSBuild Projects=”TeamCityBlogExample.sln” Properties=”Configuration=Release” />

    DependsOnTargets=”Build”>

        <NUnit Assemblies=”TeamCityBlogExample.TestsbinReleaseTeamCityBlogExample.Tests.dll”
               ContinueOnError=”false”
               ToolPath=”C:Program FilesTestDriven.NET 2.0NUnit2.4″
               OutputXmlFile=”NUnitResults.xml” />

Within the project section at the top, I set the default target to Test. This is the target which will be executed first, the Test target then has a DependsOnTarget attribute which enforces that the build must be done before we test.

On line 3, I import a reference to the MSBuild community tasks so I can access all of the custom tasks included – such as NUnit. Next I define my build target, within this I define the solution I want to build and the configuration. To execute my unit tests, I use the NUnit task from the community task project, this takes a list of all the assemblies which we need to run, define if a test fails wether it should fail the build and finally tell it where NUnit lives on the local machine.

Now, the script can be executed by a build system, such as CCNet or TeamCity, or from the command line using the msbuild.exe command and build your solution and execute your unit tests.

Download script: http://blog.benhall.me.uk/Code/Build/BaseMSBuildScript.txt

Technorati Tags: MsBuild,TeamCity

TeamCity – Creating a project step by step

On Tuesday I gave a 10 minute nugget at NxtGenUG Cambridge on how to setup a project using JetBrain’s TeamCity. TeamCity is a continuous integration server, similar to CruiseControl.NET, however I find it much more useful, easy to use and more importantly easy to manage. In this post, I thought I would explain how easy it is to setup a new TeamCity project.

Installing TeamCity is an easy process, you simply download the installer from the site and click next a few times. This will install both the server and a build agent, TeamCity allows for multiple build agents on different machines to allow you to share the load of building and running tests.

Once it has been installed, visit the webpage (for me this was localhost:8080). You will need to accept the license agreement and create an admin account. You will then be shown with the homepage for the server. Click the nice big Create project link.

You will then need to enter a friendly name for your project.

Your project has now been created. The next stage is to add a build configuration, this will be how the project monitors source control and what is executes to build the project.

After clicking Create build configuration, you will be shown the first build configuration page. Give this a friendly name, you can then enter a build number which can be used in your build scripts and on TeamCity’s UI as I described in a previous post.

Next, you can enter some artifacts, these are the files which are saved and stored on the build server. These files could be your binaries or an installer. For example, to copy everything to a buildrelease directory the syntax would be:

“**/*.* => builds/Release/”

Next stage is setup the source control which TeamCity should monitor.

Click Create and Attach new VCS root. Given this a friendly name, and select the type for example Subversion. Enter the url of the SVN server, this is the directory which will be monitored. For example, it could be https://Newbie:8443/svn/TeamCityDemo/trunk

You VCS is now setup.

The next stage is to configure the build runner. This defines how to build the project. Below, I’m using MSBuild, which when it needs to build it will execute msbuild with the script srcbuild.msbuild.

That is now your project created. The final stage is to use build triggering by ticking the enable box. This is what will cause the project to be built when you commit an item.

Your now ready to go – everything is setup. The project and builds now appear on the main homepage.

Let the automated builds begin!

Technorati Tags: TeamCity

Team City – Update AssemblyInfo with current build number

When being applications, ideally you want your assemblies to be labelled with the associated build. This will allow you to keep track of your versions, useful for bug reports, and for .NetCLR to correctly identity which version of an assembly to use. There are some disadvantages for doing this, one being you lose the flexibility to xcopy updated assemblies without having to recompile everything, this is the release why Microsoft keep versions at 2.0.0.0 (or 10.0.0.0 in the case of SQL Server 2008).

But, I want my assemblies to be labelled, as such I want to use the build counter TeamCity keeps track of when it builds my applications and have that as the value for my AssemblyVersion property. TeamCity is my current continuous integration server which uses MSBuild to compile my application, it is always best to take the build number from a CI server as it acts as a centralised point for revisions.

Within the TeamCity control panel, on the general settings page for your build configuration, you have two important boxes. The first box defines the build number format, there is then a place holder as {0} which is where TeamCity inserts it counter value. This counter value is within the second text box. Every time your project is built, this is increment. The counter contains the value which will be used for the next build.

We now have our build number in the format we want (in this case 1.0.0.28), but we need to be able to access this when the application is being built. As it happens, TeamCity provides this number within an environment variable BUILD_NUMBER which we can use within our build script via the $() syntax, the code below takes the number from TeamCity and puts it inside another variable called Version.

$(BUILD_NUMBER)

I then need to update my AssemblyInfo.cs file with this build number. The AssemblyInfo file contains all of the metadata about the assembly which is included when it is built. I just use a MSBuild community task to rewrite my complete AssemblyInfo.cs file with all of the required information.

                OutputFile=”$(MSBuildProjectDirectory)DLRHost.EnginePropertiesAssemblyInfo.cs”
                AssemblyTitle=”DLRHost.Engine”
                AssemblyDescription=”DLRHost Engine”
                AssemblyConfiguration=””
                AssemblyCompany=”Ben Hall – Blog.BenHall.me.uk”
                AssemblyProduct=”DLRHost”
                AssemblyCopyright=”Copyright (c) Ben Hall, 2008″
                AssemblyTrademark=””
                ComVisible=”false”
                CLSCompliant=”true”
                Guid=”d038566a-1937-478a-b5c5-b79c4afb253a”
                AssemblyVersion=”$(Version)”
                AssemblyFileVersion=”1.0.0.0″ />

Notice at the bottom, as the AssemblyVersion I am using my variable which contains the TeamCity build number. After the assembly has been built, if we load the assembly in Reflector you can see all of the metadata included, including the correct Version.

In summary, that is now you can attach your current build number to your assemblies with TeamCity.

Technorati Tags: TeamCity

Team City – Moving your Data Directory

After running team city for a while, and being really happy with it, I noticed that all of its configuration and all of my artifacts where being stored on under my local users folder (C:UsersBen Hall.BuildServer). On my system, I’ve moved all of my user profile information onto my E: drive, so I didn’t really want this information on my C:. I also wasn’t happy with the location because it wasn’t easy to get at to browse.

After a bit of hunting around, I found that I needed to modify the TEAMCITY.DATA.PATH property to point it to my own custom location, after a bit more hunting around I found where that property actually was.

What you need to do, is first copy the .BuildServer directory to your new location, this has all of your settings. Next load a command property (as administrator) and enter the command:

C:TeamCityBintomcat6w.exe //ES//TeamCity

This will load a TeamCity properties dialog, under Java at the bottom of the options you will find the property as shown below.

Restart the service and your done! If you get your license agreement again – your pointing to the wrong data directory.

Wiki Page: http://www.jetbrains.net/confluence/display/TCD3/System+Properties+for+Running+the+Server

Technorati Tags: TeamCity