Tuesday, June 27, 2006

Using CruiseControl.NET with MSBuild


Originated from Extreme programming, the concept of Continuous Integration has been gradually adopted to other traditional software development methodologies. I think it will bring tremendous value to our .NET based projects so I decided to set up the environment and give it a try.

CruiseControl.NET is one of the most commonly used Continuous Integration tools on the .NET platform. It works well with NAnt to build Visual Studio 2003 based projects, but as of NAnt 0.85-rc 4 there is no support for <solution> task for Visual Studio 2005 projects. As a result, NAnt can only compile Visual Studio 2005 solution on a per project basis. By default, unlike VS 2003, Visual Studio 2005 uses a new file structure based Web project, which doesn't have a project file. This imposes even more problems for NAnt to work with VS 2005 solutions.

Setting up CruiseControl.NET and NAnt to work with Visual Studio 2003 projects is relatively easy, so I will try to set up CruiseControl.NET to work with Visual Studio 2005 projects here. Since Visual Studio 2005 and .NET Framework 2.0, Microsoft introduced a new extensible, XML-based build engine named MSBuild. In fact, the solution files and project files in VS 2005 are all written in MSBuild format. So instead of using NAnt with CruiseControl.NET, we are able to leverage MSBuild for compiling VS 2005 based solutions.

Prepare to install

First make sure the project compiles with MSBuild, by checking out a fresh copy and navigate to the project root directory then issue "msbuild MyProject.sln"

Install CruiseControl.NET

Installing CruiseControl.NET is easy. Simple grab the installer from CruiseControl.NET at Thoughtworks. I also downloaded and installed CCTray. CCTray is used to view and control the build process from client side, it can be installed locally on the build server as well as remotely.

The approach

In this approach, I use CruiseControl.NET to run NAnt scripts which in turn use MSBuild for compiling the Visual Studio 2005 solution. MSBuild is more capable then just compiling, but I am more familiar with NAnt so it's easier for me to setup NAnt the way I wanted. Basically I use NAnt script to clean up directory, get source code, and call MSBuild executable to compile. I am sure CruiseControl.NET can employ MSBuild directly and MSBuild is able to do things like cleaning up the directory and getting the source code. But I won't get to that until I actually have time to learn MSBuild.

Files that will be edited/created are as follows:
  • NAnt.exe.config - NAnt config file (located in the NAnt bin directory)
  • ccnet.config - CruiseControl.NET config file (located in the CruiseControl.NET installation directory)
  • cruise.build - NAnt build script (new file created in "C:\ProjectBuild\CruiseControl.NET\server

Configure CruiseControl.NET
Add settings to ccnet.config file, add project section as follows


<intervalTrigger seconds="600" />


<sourcecontrol type="vss">







<baseDirectory>C:\ProjectBuild CruiseControl.NET\server\MyProject\WorkingDirectory


As aforementioned the configuration didn't use MSBuild directly, rather it relies on NAnt to define the build tasks.

Configure NAnt

NAnt config file
MSBuild does not come with a XML Logger by default, so I need to use an external logger to get this functionality. I download the dll from here. And then I move the ThoughtWorks.CruiseControl.MsBuild.dll file to "C:\ProjectBuild\CruiseControl.NET\Tools".

Add MSBuild property to properties section

<!--properties defined here are accessible to all build files -->
<property name="msbuild.exe"
value="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe" overwrite="false" />
<property name="msbuild.logger.class"
value="ThoughtWorks.CruiseControl.MsBuild.XmlLogger" overwrite="false" />
<property name="msbuild.logger.assembly"
value="C:\ProjectBuild\CruiseControl.NET Tools\ThoughtWorks.CruiseControl.MsBuild.dll" overwrite="false" />

NAnt build file
Finally, this is my NAnt build file

<?xml version="1.0" ?>
<target name="clean">

<delete dir="Source" failonerror="false" />

<mkdir dir="Source" />


<target name="get" depends="clean">

<vssget username="MyUserName"









<target name="build" depends="get">
<exec program="${msbuild.exe}">

<arg value="/logger:${msbuild.logger.class},${msbuild.logger.assembly}" />

<arg value="/target:Build" />

<arg value="/verbosity:minimal" />

<arg value="/noconsolelogger" />

<arg value="C:\ProjectBuild\CruiseControl.NET\server\MHI WorkingDirectory\Source\MyProject.sln" />


<target name="run" depends="build">


<project default="build">



Monday, June 26, 2006

Sharepoint 2007 comes with Blogs, Wikis and RSS

The up-coming Sharepoint 2007 will come with features found in most Portal/Content Management sites. Check out the video on Channel9 Sharepoint 2007 -- Blogs, Wikis, RSS

Thursday, June 22, 2006

Reading the Applying Domain-Driven Design and Patterns book

I am half way through reading the Applying Domain-Driven Design and Patterns book written by Jimmy Nilsson.I have always wondered how do domain-driven design, test-driven development and O/R mapper play together. Eric Evans's Domain-Driven Design: Tackling Complexity in the Heart of Software got me started on Domain-driven development. The book talked a lot about the different theories behind domain-driven development and the importance of ubiquitous language but it lacked concrete example. As a newbie to domain-driven development, I was very much in need for some concrete examples.

The Applying Domain-Driven Design and Patterns book serves as an excellent complement to Eric's book. I like author's pragmatic style. The author understands the nature of software very well so he doesn't try to establish a "standard" way of solving a problem but rather providing several solutions with their pros and cons enumerated. Therefore, I will be able to choose the best solution that fits the problem. Unfortunately, the book doesn't come with any source code and the NWorkspace framework mentioned by the author is no where found on the Internet.

Use del.icio.us for categories in blogger

I have successfully intergarted the del.icio.us category function to my blog, as you can see from the side bar to the right. Many thanks to John for his nice tutorial 3 ways to use del.icio.us for categories in blogger. As a Firefox user, I followed the third approach which uses the Greasemonkey extension with Greasemonkey script written by Johan Sundström.

Sunday, June 18, 2006

My 2 cents on agile development

In Feb 2001, 17 prominent members of the software community came together and created the Agile Manifesto. From that moment on, agile development has gradually become known to the software development world.

I got to know agile development methodology back in 2004, while I was preparing for a Co-op interview. Agile development methods are a collection of development processes including Extreme Programming, Scrum, Crystal, etc. The company was using Extreme Programming (aka XP). I was intrigued by the flexibility that the XP brings to the table. It emphasizes team communication over rigorous design documents. It boasts ideas such as customer involvement, pair programming, test driven development (TDD), and refactoring.

At my first glance, XP seems really, well, Extreme. But when I dug more into it, the whole idea makes sense. It's like that new solar powered air conditioner. Not many people thought about it but when you get to know it. It simply just makes sense.

The classic waterfall methodology and some of its alternatives treat software development process as a traditional engineering process. The development cycle is divided into several phases and executed in sequence, which is seemingly a solid practice. In building construction. Detailed and specific documents were produced and followed. Engineers know exactly what the building is going to look like and how it's going to function. Every step is carefully calculated and measured. Why? Because they have only one chance to build it right. Just like a waterfall, there is no way back.

In my opinion, these methodologies miss some vital and obvious facts:

  1. Software is Soft. It's flexible and dynamic. It tends to change over its lifetime.
  2. Software developers are capable of, and usually have to, making ad-hoc decisions during development. Design documents and development rules are hard, if not impossible, to follow and enforce.
  3. Customers usually don't know what they want , therefore, it 's impossible to envision exactly what the final product will be.
On the contrary, agile methods are adaptive and flexible. It allows software to evolve by not trying to predict unforeseeable future. Instead, detailed analysis and up-front design are integrated into every step of the coding process. In other words, developers always have the confidence and agility to perfect the design. Unlike traditional methodologies which try to avoid requirement changes, agile methods expect the software to change and grow. From a software developer's perspective TDD and Refactoring are arguably the two most significant strategies in agile development. They raise the confidence level of the developers which in turn allow them to improve design and coding while programming.

Ok, Clearly, I've used too many vague and fancy adjectives to describe agile development. Agile development is a board subject so it's impossible to cover everything in a tiny blog entry especially with a entry labeled "My 2 cents on...". So I decide to end this gutless entry here and I will elaborate on more specific topics like TDD, refactoring, and team management as I continue my endeavor to conquer agile development.

Saturday, June 17, 2006

Shell is coming to Windows

Today marks the one month milestone of this blog, although there hasn't been any new post.I have a lot technical oriented stuff to say and hopefully I will post more in the future.

I played with Windows PowerShell again yesterday. I installed it a while ago but it was very unstable so I didn't bother to give it a deeper look.
Supposedly this is one of the Windows strategies to catch up with *nix in system automation therefore it's worth another try. I downloaded the latest release candidate version and the good news is it didn't let me down this time.

Installation was easy and it requires .NET Framework 2.0. Starting the shell is somewhat slow as it runs on top of CLR. In my opinion, the most significant difference between traditional *nix and Windows PowerShell shells is *nix shells use text-based processing whereas the PowerShell uses object models based on the .NET platform.

Let me try to get all the files updated in June, 2006

PS C:\> dir | Where-Object{$_.LastWriteTime -like "*/06/2006*"}

Directory: Microsoft.PowerShell.Core\FileSystem::C:\

Mode LastWriteTime Length Name
---- ------------- ------ ----
d-r-- 14/06/2006 9:20 AM Program Files
d---- 14/06/2006 8:48 AM WINDOWS

hmm not bad. I think under the hood, the result of the dir command is contained in an object and then the object gets piped to the Where-Object command for querying.

Unlike *nix shells, files in PowerShell are still recognized by their extensions. PowerShell script has an very awkward extension "ps1", hopefully this will be changed in the final release.

check out http://channel9.msdn.com/wiki/default.aspx/Channel9.MSHQuickStart


Influence: The Psychology of Persuasion

Amazon Page ISBN-13: 978-0061241895 ISBN-10: 006124189X Do I recommend: Yes Key Takeaways Author uses a ...