While I get stick in the office for my Visual Studio theme (Yes, I like a dark background, I'm old, my eyes hurt) one thing I must recommend is the Dina monospace font .. I started using it mainly for the output windows (black with a green font looks lovely!) but now its replaced Consolas as my IDE font of choice. I often remote desktop into work and Consolas, while being very nice, only looks very nice when using ClearType .. without ? .. freaking awful! I switched over to Dinas for my main font on a whim, loved it and havent looked back. Im sure another font will trump it one day but for now Ill stop rambling !

Dina Programming Font - by Jørgen Ibsen.

FYI - All my code snippets here use this font so if you want to see them how I intended please go, grab and install this right away (hey its only 1 file !) :)

( Some folks like Liberation which is a nice font too and worth checking out if your looking for some new fontage :P )

Over the past week or so I have been trialing Team City from JetBrains (makers of Resharper et al). There has been a lot of buzz around this product and I wanted to include all the bits I had found and my thoughts on it as a product.

First a bit of background, as well as our development team we also have an application support team. Its imperative that they can get access to the latest, working builds of all our companies code. After our move to TFS we setup a series of team builds that people could run to produce DLLs / websites etc. on demand. This worked to a certain extent but wasnt perfect. A while ago we changed to running CI builds for our major projects using Cruise Control .NET and havent looked back.

CC.NET is a fantastic tool, we were able to get all the things we want, NUnit tests, code coverage (NCover), documentation generation (Sandcastle), code metrics etc but the bus factor is quite high (ie if the guy who maintains it gets run over by a bus then the rest of the team is screwed cause no one else knows how it works). The mass of XML and supporting files (BATs or MSBuild tasks) that had to be edited to get a new project up and running was quite frightening and most of the time you are copying the same config code various times. I was starting to write a large document on how to get CI up and running for new projects when I realised it was really quite stupidly complicated and began hearing good things about TeamCity.

The test I set for myself with TeamCity was  - Could I get all the things I had running with CC.NET running in TeamCity in less time and with less fiddling with config files ? The answer was suprisingly .. Yes !

The installation was very straight forward and I was up and running with zero issues. I chose a simple project to start off with, I created a source control root to monitor in TFS. The integration with TFS was seamless and posed no problems.

Next I began to setup the build. This takes the form of a 7 stage wizard ... nothing frightening here .. just common sense settings such as when you want a build to be triggered (scheduling is very nice), dependencies and runners (the things that will do the actual build). It comes with a mass of runners for Java and .NET.

For this simple setup I used the 'SLN2008' runner to build from a VS2008 Solution File in the root of my project and set it to build when i checked something in. 

NCover

I used the Ncover MSBuild tasks that come with the program .. pretty standard stuff .. one for a summary and one for a full report. Only one thing to note is that the NCover help file doesnt list the correct enum for genearting a full HTML report out so I had to get busy with Reflector to find that one ! (Its "FullCoverageReport" btw!)

The next thing to do was to declare the coverage as artifacts of the build in the configuration section of the build.

The final part (and this only has to be done once!) is to update the main config so it adds two tabs for the summary and the full report (Dont worry .. if the files arent there the tabs arent shown) 

Locate the TeamCity config file (\.BuildServer\config\main-config.xml) and add two entries.

Sandcastle

I used a pretty standard MSBuild task for Sandcastle but ran into one problem (nothing to do with TeamCity directly) .. it wouldnt run .. the script worked fine from Visual Studio, worked fine from the command line msbuild but wouldnt run when executed from within TC, one of the sandcastle tools MRefBuilder exits with Code 1 (helpful!).. turns out you need to remember to add DXROOT as an environmental variable to point to the sandcastle folder. 

.. and thats it ! All setup essentially in a few clicks .. the great thing is the tasks like adding tabs and setting environment variables only need to done once and now I can copy the configuration and futher reduce my setup times. More importantly, anyone in the team should be able to look at this config and see whats happening and tweak if needed. (Lets hope the bus thing doesnt happen quite yet though)

My experience with TeamCity, so far, has lived up to expectations .. and hopefully Ill be able to tweak it more as time goes on. Ive also found that the new vs2008 web deployment project gives a great framework for adding little MSBuild scripts even if your not used to using MSBuild .. but maybe ill blog about that another time as Im going off on a tangent ! 

Pros 

• Most basic builds are created in a few clicks.
• Duplicating build configuration is a single click - simple enough but this is really time saving.
• Artifacts - This feature, i would imagine, is designed for those people whos projects produce MSI installers etc but as a web developer I found this gave me a nice persepctive on what the actual deliverables of a web project are. In the past a build would deliver the contents as a whole web dir but now ive found myself zipping up the different parts (bin dir / main site) which should will make it more maintainable for our support team as they can just grab the bits they need !
• Custom tabs for different reports (NCover etc.)  - This means if i can add anything I want to as long as its added to my artifacts.
• Personal Builds - Bah didnt have time to talk about this but its like a sort of gatekeeper .. you can get the TC server to build your new code changes and check they work before you officially check it in .. very cool !

Cons

• Doesnt support triggering a TFS team build (as far as I can see, I had to use a custom plugin for CC.NET) - Not a huge issue but would be a nice-to-have.