I have been using CCNET for about a year now and love it. Once setup, it makes automating the process of compiling software easy and fast – which makes me and my customers happy.

Yesterday I decide, pretty much on a whim, to move my build server to a new, slightly used, server. Turns out it was pretty easy, here’s how I did it…

First, setup the new server:

• Install the same version of CCNET (version 1.4.2.14),
• Install the SVN client (if you use SVN),
• Install any other software you need to during the build process… stuff like NUnit, NAnt, the Windows SDK, and 3rd party controls (I use DevExpress), etc.

Next, stop the CCNET service on the new server and copy the ccnet.config, ccnet.exe.config, and ccservice.exe.config from the old server to the new server.
Also, copy over the build projects – for example I use NAnt, so I copied those build scripts.
Don’t forget the state files from the old server – otherwise when you run the builds on the new server the state of the build will revert to a first build state.

Restart the CCNET service on the new server and that should do it.

1.Changed the app pool of the default web site to “Classic .NET AppPool” The ccnet site is now appearing in IIS under default web.
2.Changed the app pool of ccnet site to “Classic .NET AppPool”.

WUWT readers may recall that Queens University Belfast is being asked to provide tree ring data and so far has been refusing all but a small portion. Here is an update on that story first carried in WUWT.

Guest Post by John A

Image courtesy Mississippi State University Dept of Geosciences

Following on from the last post on Doug Keenan’s struggle to get tree ring data from Queen’s University, Belfast, we have Mike Baillie from QUB to explain to Benny Peiser of CCNet:

Dear Benny,

although I am retired from basic dendrochronological work, I would like to correct a small part of the diatribe against Queen’s University, Belfast, that you carried on CCNet on the 15 August, namely the allegation that we are deliberately withholding data of climatic significance.

Your source, Mr Keenan, gives the impression that data from only one Irish oak site is available, namely Garryland Wood, Co Galway.  This is a site he used in an attempted correlation with temperature records.  He points out the problem of dealing with data from an individual site, and states that “Those problems could be at least partially addressed by considering the individual trees at the site, rather than the average for the site, and also by considering trees at other sites in the British Isles.  Doing so would presumably lead to additional increases in the correlation (that he found between Garryland tree rings and temperature records)”.

Now any fair minded reader would take it from that quotation that “the individual tree” data from Garryland is not available.  Also that same reader would take it that data from other “trees at other sites in the British Isles” are not available.  Presumably, if the data were available, Mr Keenan would have extended his analysis in the search for an even better correlation between tree-growth in the British Isles and temperature, either local or Hemispheric.

The point is, not only are the individual tree data (14 trees) available from Garryland Wood, but equivalent individual tree-ring data is available from twelve other modern oak sites in Ireland, namely Ardara, Baron’s Court, Breen Wood, Caledon, Cappoquin, Enniscorthy, Glen of the Downs, Killarney, Loch Doon, Rostrevor and Shane’s Castle.  Moreover, individual tree data is also available for seven English and Scottish sites originally sampled by myself and colleagues at Belfast.  Thus anyone wanting to undertake research on tree-rings from the British Isles with respect to climate variables simply has to go into the NOAA World Data Centre for Paleoclimatology and access the data laboriously assembled, measured, documented and presented by workers at Queen’s University Belfast.

These comments are necessary because Mr Keenan has stated on your web site that at “QUB researchers do not have the expertise to analyse the data themselves and they do not want to share their data with other researchers who do”. Personally I would like an apology from both Mssrs Keenan and Peiser. However, I don’t expect to see one.

Mike Baillie

EDITOR’S NOTE [Benny Peiser]: Mike – Thanks for your response to Doug Keenan’s account. Let me make just one correction, as far as my role as editor of CCNet is concerned. Contrary to your perception, Keenan did not publish his text on my website. He published it on a popular U.S. climate blog called “Watts Up With That.” <http://wattsupwiththat.com/2009/08/14/another-uk-climate-data-scandal-is-emerging/> I only forwarded the essay because I considered it to be in the public interest, particularly in light of the ongoing data withholding controversy surrounding CRU (see <http://www.nature.com/news/2009/090812/full/460787a.html> ). In short, just because I circulated Doug Keenan’s text does not mean that I support his views or claims. As the CCNet disclaimer states explicitly: “The opinions, beliefs and viewpoints expressed in the articles and texts and in other CCNet contributions do not necessarily reflect the opinions, beliefs and viewpoints of the editor.” I hope this clarification will reassure you. BJP

Well it appears that Doug Keenan is not apologizing or going away:

D.J. Keenan <doug.keenan@informath.org>

Following are some comments on the claims in the Response of Mike Baillie (CCNet, 18 August 2009).

The Response claims that “anyone wanting to undertake research on tree-rings from the British Isles with respect to climate variables simply has to go into the NOAA World Data Centre for Paleoclimatology and access the data laboriously assembled, measured, documented and presented by workers at Queen’s University Belfast”.

Only a tiny portion of the data from QUB is in the World Data Centre (i.e. ITRDB). For example, there is no data in the ITRDB for prior to AD 1500; yet measurements go back 7000 years–as Baillie’s own publications state.

QUB originally made the same claim, but has now admitted that most data is on disks that have not been uploaded. And the Assistant Information Commissioner has visited QUB, and confirmed that he saw much more data. That most of the data has not been uploaded and that QUB has been “deliberately withholding data of climatic significance” (Baillie’s phrase) is thus provable, acknowledged by QUB, and independently verified.

The Response also claims that my post “gives the impression that data from only one Irish oak site is available, namely Garryland Wood”. It further claims that my post implied “the individual tree data from Garryland is not available”. These claims are not based on my main post, but on the page, linked by my post, at <http://www.informath.org/apprise/a3900/b910.htm>

That page presents a short, simplified, theory how Ireland is uniquely affected by the North Atlantic Drift and deep water formation and how this links with global climate.  Briefly, if you had to pick one place in the world to study the climate, Ireland would seem to be it.

After presenting the theory to support that, the page gives a simple example, to illustrate that the theory works in practice. The example uses averages from one site in Ireland–Garryland Wood–and some basic mathematics–correlation and addition. This was done so that readers who are unfamiliar with the relevant science could judge the viability of the theory for themselves, at least to some extent. (The page was originally written for people who might not have any scientific training — staff at the Information Commissioner’s Office and the Aarhus Convention Secretariat, to support my requests for the data.)

After presenting the simplified example, the page notes that a proper analysis should consider individual trees, trees at other sites, and more sophisticated mathematics.  The claims of the Response are based on misrepresenting all this, as if the example comprised the only data and the only mathematics that were available. Those claims are thus baseless.

The Response additionally quotes from my post, “QUB researchers do not have the expertise to analyse the data themselves”, and says that Baillie wants an apology for that. If Baillie has the expertise, why did he never publish any research using it?  Moreover, I have had several discussions with Baillie over the years, and have a rough idea of his mathematical skills. The branch of statistics that seems most relevant for analyzing the data (multidimensional time series, probably nonlinear) is difficult and specialized: if Baillie can pass an introductory-level examination in the subject, I’ll pay a large sum. (Note: I would not pass either.)

To summarize, the untruthfulness in Baillie’s Response is so obvious that it seems unlikely that it was intended to be believed. Rather, this is perhaps just Baillie’s way of saying “go away”. Up until 2005, there would have been nothing that could be done.  In 2005, though, the UK Freedom of Information Act came into effect. I look forward to seeing the Act enforced for such important data.

Douglas J. Keenan
http://www.informath.org

Now all of this is really about principles – the question of ownership of scientific data and the principle of scientific replicability and analysis that can only happen if data and methodology are willingly shared.

Doug also noted to me that the blog at Nature also mentions this spat and Doug appears to think that Nature is being rather disparaging about him being  praised on Climate Audit. I can’t quite see the slight myself but then I’m not an academic trying to protect my hoard of data from hordes of unwashed mathematical analysts who “might find something wrong with it”.

I think more importantly that both Climate Audit and WUWT have both opened the way for many people to reanalyze what we’re been told by populist magazines like Nature or Science which cheerfully admits that they filter their received papers to those that are deemed “provocative” by junior editors. Its easy to see how a science magazine’s published output can be skewed to the belief system of those junior editors.

The TCP/IP model has only four layers:
. Application
. Transport
. Internet
. Network interface

We nee to understand the flow of information between two networked hosts. The OSI model describes the framework for this flow. As we move down the layers from application to physical, the data is encapsulated, which means that headers and trailers are added by each layer. The following section describes the process of creating a piece of data on one host and sending it to another host:

. At Layer 7, the user generates some data, perhaps an email message or a Word document. This data is passed down to Layer 6.

. At Layer 6, the data is formatted so that the same application on the other host can recognize and use it. The data is passed down to Layer 5.

. At Layer 5, the request to initiate a session for the transfer of the data is started. The data is passed down to Layer 4.

. At Layer 4, the data is encapsulated as either a TCP or UDP segment. The choice depends on what application generated the data. Source and destination port numbers are added, as are sequence and acknowledgment numbers and window size. The segment is passed down to Layer 3.

. At Layer 3, the segment is encapsulated with a Layer 3 header and becomes a packet. The packet header contains source and destination IP addresses and a label indicating what Layer 4 protocol it is carrying. The
packet is passed down to Layer 2.

. At Layer 2, a header with source and destination MAC addresses is added. This encapsulation creates the frame. The trailer at this layer contains an error-checking calculation called the FCS (Frame Check
Sequence). The frame header also contains a label indicating which Layer 3 protocol it is carrying (IP, IPX, and so on). The frame is sent to the interface for transmission onto the media (Layer 1).

. At Layer 1, the binary string that represents the frame is transmitted onto the media, whether electrically, optically, or by radio. Bits are transmitted across the media to the network interface of the other host.

. When received by the other host, the Layer 1 bits are sent up to Layer 2.

. At Layer 2, the destination MAC is examined to make sure that the frame was intended for this host. The FCS is calculated to check the frame for errors. If there are errors, the frame is discarded. If there are
none, the frame is decapsulated and the packet is sent to the correct Layer 3 protocol based on the protocol ID in the header.

. At Layer 3, the destination IP address is checked to see if it is intended for this host. The packet header is checked to see which Layer 4 protocol to send it to. The packet is decapsulated, and the segment is sent up to Layer 4.

. At Layer 4, the destination port in the segment header is checked and the segment is decapsulated. The data is sent to the correct upper layer application. Depending on the application, it might go directly to Layer 7 or through 5 and 6.

This process of encapsulation, transmission, and decapsulation makes data flow in an organized and manageable fashion down the OSI stack on the sender, across the transmission media, and up the OSI stack on the receiving host. It is important to understand that layer 3 on the sender is communicating with layer 3 on the receiver as well by way of the information in the headers.

The receiver has a method to tell the sender(s) to slow down the transmission rate. It’s called the sliding window. The window size indicates how many segments can be sent before an acknowledgment will be sent. If it is not busy, the receiver can handle a large number of segments and send a single acknowledgment. If it gets very busy, it can make the window size very small, allowing the sender(s) to send only a
few segments before an acknowledgment is sent. The window size of the sender and receiver is included in the segment header and can change during the lifetime of the conversation.

When a host sends a segment of data, it is labeled with a sequence number that identifies that segment and
where it belongs in the series of segments being sent. When the receiving host gets that segment, it sends an acknowledgment back to the sender with an acknowledgment number; the value of this number is the sequence number of the last segment it received, plus one. In effect, the receiver is saying, “I got your last
one, now I am ready for the next one.”
The first step in establishing a reliable connection between hosts is the three-way handshake. This initial signaling allows hosts to exchange their starting sequence numbers and to test that they have reliable communication between them.

From this point, the sender continues to send segments of data. A system known as PAR (Positive acknowledgment and Retransmission) makes sure that all the segments get where they are going. Following are the three main elements of PAR:

1. The sender starts a timer when it sends a segment, and will re-transmit that segment if the timer expires before an acknowledgment is received for that segment.

2. The sender keeps a record of all segments sent and expects an acknowledgment of each one.

3. The receiving device acknowledges the receipt of a segment by sending a segment back to the sender indicating the next sequence number it expects. If any of the segments of data should go missing—perhaps due to interference, collisions, or a link failure—the sender will not receive an acknowledgment of it
and will retransmit it. The sequence number enables the receiver to put all the segments back in the correct order.

Application:
If you are using any program or utility that can astore, send, or retrieve data over a network, it is a Layer 7 application.Some application protocol: HTTP, FTP, SMTP, POP3, NTP, TFTP, DNS, DHCP & Telnet.

Presentation Layer:
The presentation layer is responsible for formatting data so that applicationlayer protocols (and then the users) can recognize and work with it. The presentation layer does this formatting, taking the application layer data and marking it with the formatting codes so that it can be viewed reliably when accessed later.

Session Layer:
The session layer deals with initiating and terminating network connections. It provides instructions to connect, authenticate (optionally), and disconnect from a network resource.

Transport Layer:
The transport layer deals with exactly how two hosts are going to send data. The two main methods are called connection-oriented and connectionless . Connectionoriented transmission is said to be reliable, and connectionless is unreliable. Every network protocol stack will have a protocol that handles each style; in the TCP/IP stack, reliable transmission is done by TCP, and unreliable by UDP.

Network Layer:
The network layer deals with logical addressing. The last function of the network layer is to communicate with the layer above (transport) and the layer below (data link). This is achieved by attaching a header to the beginning of the segment that Layer 4 built. The addition of this header makes the segment into a packet. The packet header has a field that indicates the type of segment it is carrying—TCP or UDP, for example—so that the packet can be sent to the correct function at Layer 4. Communicating with Layer 2 in this case means that an IP packet can be sent to Layer 2 to become an Ethernet frame, Frame Relay, Point-to-Point Protocol, or almost any other Layer 2 technology.

DataLink layer:
The data link layer is responsible for taking the Layer 3 packet (regardless of which protocol created it—IP, IPX, and so on) and preparing a frame for the packet to be transmitted on the media.

Physical layer:
The physical layer defines the mechanical, procedural, and electrical standards for accessing the media so that you can transmit your Layer 2 frames.

Cisco has created a reference model for the functions its equipment performs.The three-layer hierarchical model describes the major functional roles in any networkand provides a basis for understanding and troubleshooting scalable networks.

The three-layer hierarchical model are:

Access Layer:
The access layer is the point that connects end users to the network. This can be achieved by a hub or switch to which PCs are connected, a wireless access point, a remote office connection, a dial-up service, or a VPN tunnel from the Internet into the corporate network.

Distribution Layer:
The distribution layer provides routing, packet filtering, WAN access, and QoS (Quality of Service).

A. Routing:
The access layer devices (usually switches) connect to a router or Layer 3 switch so that traffic can be routed to another network.

B. Packet Filter:
Packet filtering refers to the use of access control lists to identify certain types of traffic and control where it might go.

C. QoS:
If our network needs to use QoS features to make it run well, these features are typically first implemented
at the distribution layer.

D. Wan access
Traditional WAN access usually involves a specialized interface—perhaps a serial port or ISDN Primary Rate Interface controller.

Core layer:
The core does not usually do any routing or packet filtering, but it might do QoS if that is an important part of the network (if using Voice over IP [VoIP], for example).

Deticated leased line connection:
A leased line refers to a connection that is installed and provisioned for the exclusive use of the customer. Essentially, when you order a leased line, you get your very own piece of wire from your location to the service provider’s network. This is good because no other customer can affect your line, as can be the case with other WAN services. You have a lot of control over this circuit to do things such as Quality of Service and other traffic management. The downside is that a leased line is expensive and gets a lot more expensive if you need to connect offices that are far apart.

Circuit switched:
A circuit-switched WAN uses the phone company as the service provider, either with analog dial-up or digital ISDN connections. With circuit-switching, if you need to connect to the remote LAN, a call is dialed and a circuit is established; the data is sent across the circuit, and the circuit is taken down when it is no longer needed. Circuit-switched WANs usually use PPP, HDLC, or SLIP, and they tend to be really slow—anywhere from 19.2K for analog dialup to 128K for ISDN using a Basic Rate Interface (BRI). They can also get expensive because most contracts specify a pay-per-usage billing.

Packet Switch:
Packet-switched WAN services allow you to connect to the provider’s network in much the same way as a PC connects to a hub: When connected, your traffic is affected by other customers’ and theirs by you. This can be an issue sometimes, but it can be managed. The advantage of this shared-bandwidth technology
is that with a single physical connection from your router’s serial port (typically), you can establish virtual connections to many other locations around the world. So if you have a lot of branch offices and they are far away from the head office, a packet-switched solution is a good idea. Packet-switched circuits usually
use Frame Relay or possibly X.25.

Cell Switched:
Cell switching is similar to packet switching; the difference is that with packetswitched networks, the size of the units of data being sent (called frames) is variable. Cell-switched units (cells) are of a constant size. This makes dealing with heavy traffic loads easier and more efficient.
Cell-switched solutions such as Asynchronous Transfer Mode (ATM) tend to be big, fast, and robust.

- Cell-switched connections use fixed-length (53 bytes) packets to transmit information.

Is the method Ethernet uses to deal with collisions. When a host wants to transmit, it first listens to the wire to see if anyone else is transmitting at that moment. If it is clear, it can transmit; if not, it will wait for the host that is transmitting to stop. Sometimes, two hosts decide at the same instant that the wire is clear, and collide When this happens, the hosts that were involved with the with each other. collision send a special jam signal that advises everyone on that segment of the collision. Then all the hosts wait for a random period of time before they check the wire and try transmitting again. This wait time is tiny—a few millionths of a second—and is determined by the backoff algorithm. (The backoff algorithm is the mathematical equation a host runs to come up with the random number.) The theory is that if each host waits a different amount of time, the wire should be clear for all of them when they decide to transmit again. Any Ethernet segment that uses coaxial cable (10-BASE 2, 10-BASE 5) or a hub with twisted-pair cabling is a collision environment.

Collision domain:
A group of devices that are affected by one another’s collisions is called a collision domain.

Point-to-point:
it’s involves two hosts or devices that are directly connected to each other and nothing else. Serial communication is usually point-to-point, but not always.

Star:
A star topology is one in which one host or device has multiple connections to other hosts.
If a host wants to send to another host, it must send traffic through the hub or central device.

Ring:
A ring topology is created when one device is connected to the next one sequentially, with the last device being connected to the first. FDDI and Token Ring are examples of ring topologies.

Bus:
A bus topology uses a single coaxial cable, to which hosts are attached at intervals. Ethernet that uses coaxial cable creates a bus topology.

Mesh:
Is a topology with multiple point-to-point connections that connect each location to the others.
The advantage is that you can send data directly from any location to any other location instead of having to send it through a central point.

Ethernet:
The way Ethernet works is closely linked to its original connection type: A coaxial cable was used to join all the hosts together. This formed a segment. On a single segment, only one host could use the cable at a time; because the wire was coaxial, with one positive conductor and one negative conductor, it created a single electrical circuit. This single circuit could be energized by only one host at a time, or a conflict would result as two hosts tried to talk at once and nothing got through.

Network:
is a set of devices, software, and cables that enables the exchange of information between them.

Host Devices:
Are computers, servers, laptops, PDAs or anything a person uses to access the network.

Network Devices:
Are hubs, repeaters, bridges, switches, routers, and firewalls.

Cables:
Can be copper, fiberoptic or even wireless radio.

Set once and let it go, this is how Continuous Integration works for automated build process along with development cycle. For a large number of projects, the maintenance for such continously integrated build environment could be complicate and cumbersome. This article will provide and discuss sample config files from practice experience to make easy using CruiseControl.NET and CruiseControl with subversion repository. For comparison of all other similar products, see ThoughtWorks CI Feature Matrix.

Contents

• CruiseControl.NET – [see online documentation]
• CruiseControl – [see configuration reference]
• Comparison

CruiseControl.NET

CCNET (CruiseControl.NET) starts with ccnet.config:

<!--ccnet.config-->
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE cruisecontrol SYSTEM "file:ccnet_definitions.dtd">

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
  <cb:include href="ccnet_definitions.xml" xmlns:cb="urn:ccnet.config.builder"/>

  <queue name="$(computername)" duplicates="ApplyForceBuildsReAdd" />
  <cb:include href="ccnet_Project.Standard_Solution.xml" xmlns:cb="urn:ccnet.config.builder"/>

  <cb:include href="ccnet_MyProject.xml" xmlns:cb="urn:ccnet.config.builder"/>
</cruisecontrol>

In order to maintain CCNET config and projects in clear XML code, the ccnet.config in above example takes advantage of CCNET powerful preprocessor features. There are three types of CCNET configuration preprocessors: constant (including text/variable and nodeset XML fragment), nested expansion (defining a class whose instance can take parameters), and include file (<cb:include />).

Including external config files helps putting constant/variable definitions, project definitions, and reusable XML pieces together in an organized structure, so that ccnet.config can be read in a from-top-to-down order while presenting high-level view in the main config. Another advanced use of include files is to allow editing definition or project file individually without touching ccnet.config. CCNET has the ability to notice any include file changed and reload ccnet.config automatically.

Like writing a program, the first thing in design is to define constants, variables, and reusable functions (or templates) that can be shared across the projects. These are all implemented by <cb:define /> in CCNET. Constants and XML fragments can be defined by DTD, such as in XHTML DTDs and following sample of ccnet_definitions.dtd included in ccnet.config.

<!--ccnet_definitions.dtd-->
<!ENTITY dir_ccnet "$(ProgramFiles)\CruiseControl.NET">
<!ENTITY dir_ccnet_server "$(ProgramFiles)\CruiseControl.NET\server">
<!ENTITY dir_ccnet_artifacts "$(ProgramFiles)\CruiseControl.NET\server\projects">
<!ENTITY dir_svn "$(ProgramFiles)\CollabNet Subversion Server">
<!ENTITY dir_svn_target "\\10.0.1.100\svnbuilds">
<!ENTITY dir_dotnet "$(SystemRoot)\Microsoft.NET\Framework\v3.5">
<!ENTITY dir_msvs "$(ProgramFiles)\Microsoft Visual Studio 9.0">

<!ENTITY svn_server "svn://192.168.0.100">
<!ENTITY auth_svn "<username>svn_user</username><password>svn_password</password>" >

<!ENTITY exec_devenv "<executable>&dir_msvs;\Common7\IDE\devenv.com</executable>" >
<!ENTITY exec_nmake "<executable>&dir_msvs;\VC\bin\nmake.exe</executable>" >
<!ENTITY exec_msbuild "<executable>&dir_dotnet;\MSBuild.exe</executable>" >
<!ENTITY exec_svn "<executable>&dir_svn;\svn.exe</executable>" >

<!ENTITY url_ccnet "http://localhost/ccnet">

However, entity definition has its limitation in use (such as in string value of a property) and modifying a system file included by <!DOCTYPE > cannot trigger ccnet.config to reload. In CCNET, <cb:define /> is recommended to perform the same and even better job. The following sample illustrates syntax of defining text constant (variable) and nodeset (xml fragment). The third usage of <cb:define />, nested expansion, is for reusable class that can take parameters by instance, such as defining a project template.

<!--ccnet_definitions.xml-->
<cb:config-template xmlns:cb="urn:ccnet.config.builder">
<!--# Preprocessor: Text Constants -->
  <cb:define const_name="value" /> <-- defines $(const_name), or <cb:const_name/> -->
  <cb:define dir_ccnet="$(ProgramFiles)\CruiseControl.NET" />
  <cb:define dir_ccnet_server="$(dir_ccnet)\server" />
  <cb:define dir_ccnet_artifacts="$(dir_ccnet_server)\projects" />
  <cb:define dir_ccnet_buildlogger="$(dir_ccnet)\server\ThoughtWorks.CruiseControl.MsBuild.dll" />
  <cb:define dir_dotnet="$(SystemRoot)\Microsoft.NET\Framework\v3.5" />
  <cb:define dir_svn="$(ProgramFiles)\CollabNet Subversion Server" />
  <cb:define dir_svn_source="c:\svn_checkout" />
  <cb:define dir_svn_builds="d:\svn_builds" />
  <cb:define dir_svn_target="\\10.0.1.100\svnbuilds" />
  <cb:define dir_system32="$(SystemRoot)\system32" />
  <cb:define dir_msvs="$(ProgramFiles)\Microsoft Visual Studio 9.0" />

  <cb:define svn_username="svn_username" />
  <cb:define svn_password="svn_password" />

  <cb:define url_svn_target="file://///10.0.1.100/svnbuilds" />
  <cb:define url_ccnet="http://localhost/ccnet" />

<!--# Preprocessor: Nodeset Constants -->
  <cb:define name="xml_default_extlink">
    <externalLink name="CCNET Builds [Ctrl+Click to open in Explorer]" url="$(url_svn_target)" />
  </cb:define>
  <cb:define name="xml_logger">
    <xmllogger logDir="$(dir_ccnet_server)\projects" />
  </cb:define>

  <cb:define name="auth_svn">
    <username>$(svn_username)</username>
    <password>$(svn_password)</password>
  </cb:define>
  <cb:define name="exec_devenv">
    <executable>$(dir_msvs)\Common7\IDE\devenv.com</executable>
  </cb:define>
  <cb:define name="exec_nmake">
    <executable>$(dir_msvs)\VC\bin\nmake.exe</executable>
  </cb:define>
  <cb:define name="exec_vcvars">
    <executable>$(dir_msvs)\VC\vcvarsall.bat</executable>
    <baseDirectory>$(dir_msvs)\VC</baseDirectory>
    <buildArgs>x86</buildArgs>
  </cb:define>
  <cb:define name="exec_msbuild">
    <executable>$(dir_dotnet)\MSBuild.exe</executable>
  </cb:define>
  <cb:define name="exec_svn">
    <executable>$(dir_svn)\svn.exe</executable>
  </cb:define>

<!--# Preprocessor: Nested Expansions (see other ccnet_*.xml)
  <cb:define name="xml_element"><some_element property="$(var1)" /><more>$(var2)</more></cb:define>
  <cb:xml_element var1="value1" var2="value2" />
-->

</cb:config-template>

The use of definitions in CCNET is easy to understand from above sample config file. First of all, any system environment variables can be referenced by $(env_var), where $(env_var) is an environment variable accessible in CCNET runtime context. For example, if CCNET is started by ccnet.exe manually in a Command Prompt window, all system variables and logon user variables should be available; otherwise, if CCNET is started in service.msc, only system variables can be used.

Once a CCNET constant/variable (<cb:define var_name="text" />) or XML fragment (<cb:define name="element_name" >...</cb:define>) is defined, it can be referenced immediately afterward thru whole CCNET runtime environment. The constant/variable can be referenced as a string by $(var_name), or <cb:var_name />. The XML fragment must be referenced by <cb:element />. All <cb:define /> are global definitions. To control the scope of a preprocessor definition, use <cb:scope />. See configuration preprocessors.

Next, let’s take a look at how to use CCNET nested expansions and parameters of preprocessor definition to create a project template. This template can be used to meet the following conditions:

• All project properties can be initiated by an instance of the template
• There is only one build target path needed to be published
• There is only one developer and who will be in notification for all build states
• The project can be built by a MS Visual Studio 2008 solution file

Similar to ccnet_definitions.xml, ccnet_Project.Standard_Solution.xml uses <cb:config-template /> but only defines one XML fragment named “project_template_solution“.

<!--ccnet_Project.Standard_Solution.xml-->
<?xml version="1.0" encoding="utf-8" ?>
<cb:config-template xmlns:cb="urn:ccnet.config.builder">
<cb:define name="project_template_solution">
<project name="$(project_name)" queue="$(project_queue)" queuePriority="0">
  <category>$(project_category)</category>
  <workingDirectory>$(dir_svn_source)\$(project_name)</workingDirectory>
  <artifactDirectory>$(dir_ccnet_artifacts)\$(project_name)</artifactDirectory>
  <webURL>$(url_ccnet)</webURL>

  <labeller type="svnRevisionLabeller">
    <prefix>$(project_name)-r</prefix>
    <major>0</major>
    <minor>0</minor>
    <url>svn://$(project_svnServer)$/(project_Root)$(project_Path)/$(project_Branch)</url>
    <cb:auth_svn />
  </labeller>
  <!--
  <labeller type="lastChangeLabeller"><prefix>$(project_name)-</prefix></labeller>
  -->
    <triggers>
    <!--NOTE: build machine must sync clock with svn server!!!-->
    <intervalTrigger buildCondition="IfModificationExists" seconds="$(project_checkTime)" initialSeconds="60" />
  </triggers>
  <sourcecontrol type="svn">
    <trunkUrl>svn://$(project_svnServer)$/(project_Root)$(project_Path)/$(project_Branch)</trunkUrl>
    <cb:auth_svn />
    <cb:exec_svn />
    <workingDirectory>$(dir_svn_source)\$(project_name)</workingDirectory>
    <timeout units="seconds">$(project_checkTime)</timeout>
  </sourcecontrol>

  <tasks>
    <msbuild>
      <cb:exec_msbuild />
      <projectFile>$(project_solution)</projectFile>
      <workingDirectory>$(dir_svn_source)\$(project_name)</workingDirectory>
      <buildArgs>/noconsolelogger /p:Configuration=Release</buildArgs>
      <logger>$(dir_ccnet_buildlogger)</logger>
    </msbuild>
  </tasks>

  <publishers>
    <cb:xml_logger />

    <buildpublisher>
      <sourceDir>$(dir_svn_source)\$(project_name)\$(project_buildTarget)</sourceDir>
      <publishDir>$(dir_svn_target)</publishDir>
      <useLabelSubDirectory>true</useLabelSubDirectory>
      <alwaysPublish>false</alwaysPublish>
    </buildpublisher>

    <cb:include href="ccnet_email.xml" xmlns:cb="urn:ccnet.config.builder" />
    <cb:ccnet_email
        developer_name="Developer" developer_alias="$(project_developer)"
        notification="Always"
        />
  </publishers>

</project>
</cb:define>

</cb:config-template>

Different from ccnet_definitions.xml, ccnet_Project.Standard_Solution.xml also uses some variables that have never been defined, such as $(project_name), $(project_path), and etc., basically anything with “project_” prefix in this example. This is the exclusive feature of CCNET preprocessor that allow all these variable dynamically bound to an instance of the template when it is used. In ccnet.config, after ccnet_Project.Standard_Solution.xml is loaded, a project file ccnet_MyProject.xml comes after to initiate a project configuration based on the template. Here is code:

<!--ccnet_MyProject.xml-->
<cb:config-template xmlns:cb="urn:ccnet.config.builder">
<cb:project_template_solution
    project_name="My Project"
    project_alias="myproject"
    project_category="My Category"
    project_path="MyProject"
    project_root=""
    project_branch="trunk"
    project_svnServer="192.168.10.100"
    project_svnPath="svn://192.168.10.100/Software/MyProject/trunk"
    project_solution="MyProject.sln"
    project_buildTarget="Setup\Release"
    project_buildTime="1800"
    project_checkTime="600"
    project_developer="myalias"
    project_queue="$(computername)"
/>

</cb:config-template>

The properties defined in “My Project” configuration makes the template used in complete. Actually, the property names after cb:project_template_solution may not be necessary matching what have been defined in the template. At least CCNET does not check if a referenced constant or variable is predefined. Undefined constant/variable will be replaced by empty string (- be caution that this could cause exception at the runtime). And any property defined in the instance but not used in the template will be ignored (e.g. project_svnPath).

CCNET preprocessor config template can be nested. Here is the file of ccnet_email.xml that has been included in ccnet_Project.Standard_Solution.xml:

<!--ccnet_email.xml-->
<cb:config-template xmlns:cb="urn:ccnet.config.builder">

  <cb:define name="ccnet_email">
    <email from="Builder@mycompany.com"
           mailhost="192.168.10.25" includeDetails="TRUE" useSSL="FALSE"
           subjectPrefix="CCNET:" description="CruiseControl.NET E-mail Notification ">
      <users>
        <user name="Builder" group="Builder" address="builder@mycompany.com"/>
        <user name="$(developer_name)" group="Developer" address="$(developer_alias)@mycompany.com"/>
        <user name="Build Request" group="Supervisor" address="buildrequest@mycompany.com"/>
        <user name="Admin" group="Admin" address="admin@mycompany.com"/>
      </users>
      <groups>
        <group name="Admin" notification="Failed"/>
        <group name="Builder" notification="Success"/>
        <group name="Developer" notification="$(notification)"/>
      </groups>

      <modifierNotificationTypes>
        <NotificationType>Always</NotificationType>
        <NotificationType>Failed</NotificationType>
        <NotificationType>Fixed</NotificationType>
        <NotificationType>Success</NotificationType>
        <NotificationType>Change</NotificationType>
      </modifierNotificationTypes>

      <subjectSettings>
        <subject buildResult="Broken" value="Build Failed - ${CCNetProject} - [Broken] :: ${CCNetBuildCondition}" />
        <subject buildResult="StillBroken" value="Build Failed - ${CCNetProject} - [StillBroken] :: ${CCNetBuildCondition}" />
        <subject buildResult="Fixed" value="Build Success - ${CCNetProject} - [Fixed] :: ${CCNetBuildCondition}" />
        <subject buildResult="Exception" value="Build Failed - ${CCNetProject} - [Exception] :: ${CCNetBuildCondition}" />
        <subject buildResult="Success" value="Build Success - ${CCNetProject} - [Success] :: ${CCNetBuildCondition}" />
      </subjectSettings>
    </email>
  </cb:define>

  <!--# after <cb:include href="ccnet_email.xml" />, define following properties:
        developer_name  - developer name
        developer_alias - developer email alias
        notification    - notification type: Always|Change|Failed|Success|Fixed
  <cb:ccnet_email
      developer_name=""
      developer_alias=""
      notfication=""
    />
  ==-->
</cb:config-template>

For label variables used in <subjectSettings />, please refer to CCNET Email Publisher.

The last thing left uncovered in the project template is “svnRevisionLabeller”. This is a modified plugin based on original svnrevisionlabeller. The code (SvnRevisonLabeller.cs) is attached below:

/**
 ****************************************
 * Class Name:  SvnRevisionLabeller
 * Description: Subversion functions used in NAnt
 * Requisite:   Reference to NAnt.Core.dll
 * Notes:       See http://code.google.com/p/svnrevisionlabeller/
 ****************************************
 */
using System;
using System.Xml;
using Exortech.NetReflector;
using ThoughtWorks.CruiseControl.Core;
using ThoughtWorks.CruiseControl.Core.Util;

namespace ccnet.SvnRevisionLabeller.plugin
{
 /// <summary>
 /// Generates label numbers using the Subversion revision number.
 /// </summary>
 /// <remarks>
 /// This class was inspired by Jonathan Malek's post on his blog
 /// (<a href="http://www.jonathanmalek.com/blog/CruiseControlNETAndSubversionRevisionNumbersUsingNAnt.aspx">CruiseControl.NET and Subversion Revision Numbers using NAnt</a>),
 /// which used NAnt together with Subversion to retrieve the latest revision number. This plug-in moves it up into
 /// CruiseControl.NET itself, so that you can see the latest revision number appearing in CCTray. The label can
 /// then be retrieved from within NAnt by accessing the property <c>${CCNetLabel}</c>.
 /// </remarks>
 [ReflectorType("svnRevisionLabeller")]
 public class SvnRevisionLabeller : ILabeller
 {
  #region Private members

  private int major;
  private int minor;
  private string _url;
  private string executable;
  private string prefix;
  private string username;
  private string password;
  private const string RevisionXPath = "/log/logentry/@revision";

  #endregion

  #region Constructors

  /// <summary>
  /// Initializes a new instance of the <see cref="SvnRevisionLabeller"/> class.
  /// </summary>
  public SvnRevisionLabeller()
  {
   major = 1;
   minor = 0;
   executable = "svn.exe";
   prefix = String.Empty;
  }

  #endregion

  #region Public methods

  /// <summary>
  /// Returns the label to use for the current build.
  /// </summary>
  /// <param name="resultFromLastBuild">IntegrationResult from last build used to determine the next label</param>
  /// <returns>the label for the new build</returns>
  public string Generate(IIntegrationResult resultFromLastBuild)
  {
   // Get the last revision from the Subversion repository
   int svnRevision = GetRevision();

   // Get the last revision from CruiseControl
   Version version = ParseVersion(svnRevision, resultFromLastBuild);

   // If the revision number hasn't changed (because no new check-ins have been made), increment the build number;
   // Otherwise, reset the build number to 0
   int revision = (svnRevision == version.Build) ? version.Revision + 1 : 0;

   // Construct a new version number, adding any specified prefix
   Version newVersion = new Version(major, minor, svnRevision, revision);

            if (major == 0 && minor == 0)
            {
                // <major>0</major><minor>0</minor> must be explicitly defined
                // assume we only care about subversion revision - 2008-11-18 jzhu@zetron.com
                return prefix + svnRevision;
            }
            else // keep original usage for a 4-field version format
            {
                return prefix + newVersion;
            }
  }

  /// <summary>
  /// Runs the task, given the specified <see cref="IIntegrationResult"/>, in the specified <see cref="IProject"/>.
  /// </summary>
  /// <param name="result"></param>
  public void Run(IIntegrationResult result)
  {
   result.Label = Generate(result);
  }

  #endregion

  #region Public properties

  /// <summary>
  /// Gets or sets the major build number.
  /// </summary>
  /// <value>The major build number.</value>
  [ReflectorProperty("major", Required=false)]
  public int Major
  {
   get
   {
    return major;
   }
   set
   {
    major = value;
   }
  }

  /// <summary>
  /// Gets or sets the minor build number.
  /// </summary>
  /// <value>The minor build number.</value>
  [ReflectorProperty("minor", Required=false)]
  public int Minor
  {
   get
   {
    return minor;
   }
   set
   {
    minor = value;
   }
  }

  /// <summary>
  /// Gets or sets the repository URL from which the <c>svn log</c> command will be run.
  /// </summary>
  /// <value>The repository.</value>
  [ReflectorProperty("url", Required = true)]
  public string Url
  {
   get
   {
    return _url;
   }
   set
   {
    _url = value;
   }
  }

  /// <summary>
  /// Gets or sets the Subversion client executable.
  /// </summary>
  /// <value>The path to the executable.</value>
  /// <remarks>
  /// If the value is not supplied, the task will expect to find <c>svn.exe</c> in the <c>PATH</c> environment variable.
  /// </remarks>
  [ReflectorProperty("executable", Required=false)]
  public string Executable
  {
   get
   {
    return executable;
   }
   set
   {
    executable = value;
   }
  }

  /// <summary>
  /// Gets or sets an optional prefix for the build label.
  /// </summary>
  /// <value>A string to prefix the version number with.</value>
  [ReflectorProperty("prefix", Required=false)]
  public string Prefix
  {
   get
   {
    return prefix;
   }
   set
   {
    prefix = value;
   }
  }

  /// <summary>
  /// Gets or sets the username to access SVN repository.
  /// </summary>
  /// <value>The repository.</value>
  [ReflectorProperty("username", Required = false)]
  public string Username
  {
   get
   {
    return username;
   }
   set
   {
    username = value;
   }
  }

  /// <summary>
  /// Gets or sets the password to access SVN repository.
  /// </summary>
  /// <value>The repository.</value>
  [ReflectorProperty("password", Required = false)]
  public string Password
  {
   get
   {
    return password;
   }
   set
   {
    password = value;
   }
  }

  #endregion

  #region Private methods

  /// <summary>
  /// Parses the version.
  /// </summary>
  /// <param name="revision">The revision.</param>
  /// <param name="resultFromLastBuild">The result from last build.</param>
  private Version ParseVersion(int revision, IIntegrationResult resultFromLastBuild)
  {
   try
   {
    string label = resultFromLastBuild.LastSuccessfulIntegrationLabel;
    if (prefix.Length > 0)
    {
     label = label.Replace(prefix, String.Empty).TrimStart('_');
    }
    return new Version(label);
   }
   catch (SystemException)
   {
    return new Version(major, minor, revision, 0);
   }
  }

  /// <summary>
  /// Gets the latest Subversion revision by checking the last log entry.
  /// </summary>
  private int GetRevision()
  {
   // Set up the command-line arguments required
   ProcessArgumentBuilder argBuilder = new ProcessArgumentBuilder();
   argBuilder.AppendArgument("log");
   argBuilder.AppendArgument("--xml");
   argBuilder.AppendArgument("--limit 1");
   argBuilder.AppendArgument(Url);
   if (Username != null && Username.Length > 0 && Password != null && Password.Length > 0)
   {
    AppendCommonSwitches(argBuilder);
   }

   // Run the svn log command and capture the results
   ProcessResult result = RunProcess(argBuilder);
   Log.Debug("Received XML : " + result.StandardOutput);

   // Load the results into an XML document
   XmlDocument xml = new XmlDocument();
   xml.LoadXml(result.StandardOutput);

   // Retrieve the revision number from the XML
   XmlNode node = xml.SelectSingleNode(RevisionXPath);
   return Convert.ToInt32(node.InnerText);
  }

  /// <summary>
  /// Appends the arguments required to authenticate against Subversion.
  /// </summary>
  /// <param name="buffer"><The argument builder./param>
  private void AppendCommonSwitches(ProcessArgumentBuilder buffer)
  {
   buffer.AddArgument("--username", Username);
   buffer.AddArgument("--password", Password);
   buffer.AddArgument("--non-interactive");
   buffer.AddArgument("--no-auth-cache");
  }

  /// <summary>
  /// Runs the Subversion process using the specified arguments.
  /// </summary>
  /// <param name="arguments">The Subversion client arguments.</param>
  /// <returns>The results of running the process, including captured output.</returns>
  private ProcessResult RunProcess(ProcessArgumentBuilder arguments)
  {
   ProcessInfo info = new ProcessInfo(executable, arguments.ToString(), null);
   Log.Debug("Running Subversion with arguments : " + info.Arguments);

   ProcessExecutor executor = new ProcessExecutor();
   ProcessResult result = executor.Execute(info);
   return result;
  }
  #endregion
 }
}

CruiseControl

Comparing to CCNET, CruiseControl does not provide very powerful preprocessor and template feature. There is no syntax to define XML fragment (except using DTD). The main config file, config.xml, cannot be automatically reloaded if any configuration changed.

<!--config.xml-->
<?xml version="1.0" encoding="utf-8" ?>
<!--# Always deploy ccnet.config with following files under ${env.CCDIR}
                    config.properties
                    cc_antpublisher_copy.xml
                    prj_*.xml
      also place cruisecontrol.jar under "${env.CCDIR}\lib" to overwrite
      original one for a customized new plugin: <ZSVNLabeller />
==-->
<cruisecontrol>
  <property file="config.properties" />
  <property environment="env" toupper="true" />
  <property name="url_cruisecontrol" value="${url_cchost}/cruisecontrol" />
  <property name="url_buildresults" value="${url_cruisecontrol}/buildresults" />
  <property name="url_ccdashboard" value="${url_cchost}/dashboard" />
  <property name="url_ccdoc" value="${url_cchost}/documentation" />

  <include.projects file="prj_MyProject.xml" />

</cruisecontrol>

As in above sample of config.xml, property definition is either by <property name="var" value="text" /> element or an external file (e.g. config.properties).

###############################################################################
# Filename: config.properties
#    Usage: called by cruisecontrol element, i.e.:
#           <property file="config.properties" />
#   Syntax: defined by the class java.util.Properties, with the same rules
#           about how non-ISO8859-1 characters must be escaped.
###############################################################################

### default value predefinitions
def_hostip=10.0.1.194
def_hostname=hostname
def_project_buildTime=1800
def_project_checkTime=600

### dir/path predefinitions
dir_cruisecontrol=%ProgramFiles%\CruiseControl
dir_svn_target=\\10.0.1.100\svnbuilds
pwd_cruisecontrol=/srv/cruisecontrol-bin-2.8.2
smb_svn_target=/svnbuilds

### svn settings predefinitions
svn_server=svn://192.168.10.100
svn_username=svn_username
svn_password=svn_password

### user id predefinitions
uid_admin=admin
uid_builder=builder

### url predefinitions
url_cchost=http://hostname:8080
url_ccdashboard=http://hostname:8080/dashboard
url_ccdoc=http://hostname:8080/documentation
url_cruisecontrol=http://hostname:8080/cruisecontrol
url_buildresults=http://hostname:8080/cruisecontrol/buildresults
url_ccnet=http://localhost/ccnet

Certainly, a project file (e.g. prj_MyProject.xml) can be included in config.xml so that the configuration is well organized by each individual config file. Here only provides a project template file that a real project config (e.g. prj_MyProject.xml) will be based on.

<!--prj_project.template.xml-->
<?xml version="1.0" encoding="utf-8" ?>
<!--#
  For each project, use following steps to create a project file from this template by
  copying this file to a new project file, in convention of "prj_$[project_name].xml":
  (1) replace "$[project_name]" with a project name
  (2) replace any place holder definition, like in format of $[place_holder], in property definitions
  (3) optionally use ${def_project_buildTime} for ${project_buildTime}
  (4) optionally add more ${project_buildTarget[n]} properties and publishers
  (5) choose one of the build methods in <project><schedule></schedule></project> block
  (6) replace "\\" to "/" on Linux system
  (7) replace ${dir_svn_target} with ${smb_svn_target} on a Linux build system
  (8) define properties ${eid_*} for build notification; ${uid_builder} has been notified on success
  (9) refer to any property definitions in config.properties
==-->
<cruisecontrol>
  <project name="$[project_name]">
    <property name="project_name"        value="${project.name}" />
    <property name="project_alias"       value="$[project_alias]" />
    <property name="project_category"    value="$[project_category]" />
    <property name="project_root"        value="$[project_root]" />
    <property name="project_path"        value="$[project_path]" />
    <property name="project_branch"      value="$[project_branch]" />
    <property name="project_svnServer"   value="$[project_svnServer]" />
    <property name="project_svnPath"     value="svn://${project_svnServer}/${project_root}${project_path}/${project_branch}" />
    <property name="project_source"      value="${env.CCDIR}\\projects\\${project.name}" />
    <property name="project_buildTarget" value="$[project_buildTarget]" />
    <property name="project_buildTime"   value="${def_project_buildTime}" />
    <property name="project_buildTime"   value="$[project_buildTime]" />
    <property name="project_checkTime"   value="30" />
    <property name="url_cruisecontrol"   value="${url_cruisecontrol}" />
    <property name="eid_failure"         value="builder" />
    <property name="eid_success"         value="builder" />
    <property name="eid_always"          value="developer_alias" />

    <plugin name="svn" classname="net.sourceforge.cruisecontrol.sourcecontrols.SVN" />
    <plugin name="ZSVNLabeller" classname="net.sourceforge.cruisecontrol.labelincrementers.ZSVNLabeller" />

    <ZSVNLabeller separator="r" labelprefix="r" workingcopypath="${project_source}"
                  />
    <!--#
    <listeners>
      <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
    </listeners>
    ==-->
    <bootstrappers>
      <!--#
      <antbootstrapper anthome="apache-ant-1.7.0"
                       buildfile="projects/${project.name}/build.xml"
                       target="clean" />
     <execbootstrapper command=""
                       args="" workingdir="projects/${project.name}"
                       errorstr="" showProgress=""
                       timeout=""
                       />
      ==-->
      <svnbootstrapper localWorkingCopy="${project_source}"
                       username="${svn_username}"
                       password="${svn_password}"
                       />
    </bootstrappers>

    <modificationset quietperiod="60">
      <!--# <filesystem/> triggers a build if any file in ${project.name} project is touched
      <filesystem folder="${project_source}" includedirectories="false" />
      ==-->
      <!--# <svn/> sets property ${svnrevision}
      ==-->
      <svn localWorkingCopy="${project_source}"
           useLocalRevision="false"
           username="${svn_username}"
           password="${svn_password}"
           property=""
         />
    </modificationset>

    <schedule interval="{project_checkTime}">
      <!--#<ant />
      <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml"/>
      ==-->
      <!--#<exec/>
      ==-->
      <exec command=".\\build.cmd"
            args='"${project_source}"' workingdir="${project_source}"
            errorstr="Build Failed" showProgress="true"
            timeout="${project_buildTime}"
            />
    </schedule>

    <log>
      <!--# merge from log files with specified pattern from specified dir
      <merge dir="${project_source}\\log" pattern="*.log" />
      ==-->
      <deleteartifacts every="30" unit="DAY" />
      <delete every="30" unit="DAY" />
    </log>

    <publishers>
      <htmlemail buildresultsurl="${url_cruisecontrol}/buildresults/${project_name}"
                 defaultsuffix=".com" mailhost="192.168.10.66" mailport="25" usessl="false"
                 returnaddress="builder@mycompany.com" returnname="Builder"
                 subjectprefix="CruiseControl:"
           >
        <success address="${uid_builder}@mycompany.com" /><!--send to builder success notification-->
        <success address="${eid_success}@mycompany.com" />
        <failure address="${eid_failure}@mycompany.com" />
        <always  address="${eid_always}@mycompany.com"  />
      </htmlemail>

      <onsuccess>
        <antpublisher anthome="apache-ant-1.7.0"
                      buildfile="${env.CCDIR}\\cc_antpublisher_copy.xml"
                      target="publish_dir"
                      >
          <property name="publish_source" value="${project_source}\\${project_buildTarget}" />
          <property name="publish_target" value="${dir_svn_target}\\${project_alias}" />
        </antpublisher>
        <!--
        <antpublisher anthome="apache-ant-1.7.0"
                      buildfile="${env.CCDIR}\\cc_antpublisher_copy.xml"
                      target="publish_file"
                      >
          <property name="publish_source" value="${project_source}\\${project_buildTarget}" />
          <property name="publish_target" value="${dir_svn_target}\\${project_alias}" />
        </antpublisher>
        ==-->
      </onsuccess>
    </publishers>

  </project>

</cruisecontrol>

The template cannot be used as nicely as in CCNET. But it gives a start for most projects. Please refer to usage comments at beginning of the template. Also remember since CruiseControl is running on both Windows and Linux systems, backslash or forward-slash need to be carefully used wherever a path is typed.

One of the difference in CruiseControl than CCNET is the sequence of continuous integration cycle. In CCNET, the <sourcecontrol /> compares last build state with repository server, then checkout (for the first time of check) or update source code on local working directory before starting build tasks. But in CruiseControl, the bootstrapper is always called at the beginning to update local working directory from server before using <modificationset /> to detect if tasks in <schedule /> need to be executed.

Such difference implies that the local working directory and source code in CruiseControl project must be manually checked out from the repository (such as `svn co`) at the time when the project is setup, which is not necessary in CCNET – where the local working directory can be created automatically if it does not exist. This also explains why LocalWorkingCopy (rather than RepositoryLocation) property should be used in <svn /> source control under <modificationset /> to detect new commit for a CruiseControl project.

Note: There could be a chance that local working copy has not been updated yet when a new change is committed on repository server after bootstrapper but before modificationset. The race condition will end up building old source against a newer revision label.

Modification of subversion in CruiseControl is parsed from `svn log -r` by checking between last build time and current time. If useLocalRevision property is used in <svn /> source control, the local revision number will be in place of current time.

At the end of the template, artifacts publishing is implemented by the following include file.

<!--cc_antpublisher_coppy.xml-->
<project name="antpublisher_copy" default="publish">
    <target name="publish">
        <echo>Copying ${publish_source} to ${publish_target} ...</echo>
        <copy todir="${publish_target}"><fileset dir="${publish_source}" /></copy>
    </target>
    <target name="publish_dir">
        <echo>Copying ${publish_source} to ${publish_target}-${label} ...</echo>
        <copy todir="${publish_target}-${label}"><fileset dir="${publish_source}" /></copy>
    </target>
    <target name="publish_file">
        <echo>Copying ${publish_source} to ${publish_target}-${label} ...</echo>
        <copy todir="${publish_target}-${label}" file="${publish_source}"></copy>
    </target>
    <target name="publish_artifacts">
        <echo>Copying ${publish_source_dir} to ${publish_target} ...</echo>
        <copy todir="${publish_target}">
   <fileset dir="${publish_source_dir}">
    <include name="${publish_source_files}" />
   </fileset>
  </copy>
    </target>
</project>

The Java source code of “ZSVNLabeller” plugin (based on SVNLabelIncrementer, implements LabelIncrementer) is attached as below. The file “ZSVNLabeller.java” should be place under source code folder “net\sourceforge\cruisecontrol\labelincrementers“. After rebuilt, copy “cruisecontrol.jar” to ${env.CCDIR}, where CruiseControl installed.

package net.sourceforge.cruisecontrol.labelincrementers;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

import net.sourceforge.cruisecontrol.LabelIncrementer;

import org.apache.log4j.Logger;
import org.jdom.Element;

/**
 * This class provides a label incrementation based on svn revision numbers.
 * This class expects the label format to be "x<sep>y[<sep>z]",
 * where x is any String and y is an integer and <sep> a separator, the
 * last part z, is optional, and gets generated and later incremented in case a
 * build is forced. The default separator is "." and can be modified using
 * {@link #setSeparator}.
 *
 * @author Ketan Padegaonkar < KetanPadegaonkar gmail >
 */

/// UPDATE: return revisionNumber if separator is as same as prefix - Boathill

public class ZSVNLabeller implements LabelIncrementer {
    private static final Logger LOG = Logger.getLogger(ZSVNLabeller.class);

    private String workingCopyPath = ".";

    private String labelPrefix = "svn";

    private String separator = ".";

    public boolean isPreBuildIncrementer() {
        return true;
    }

    public String incrementLabel(String oldLabel, Element buildLog) {
        String revisionNumber = "";
        String result = oldLabel;
        try {
            revisionNumber = getSvnRevision();

            if (getSeparator().equals(getLabelPrefix())) {
                return labelPrefix + revisionNumber; // return svn revison only
            }
            if (revisionNumber == null || revisionNumber.equals("")) {
                return labelPrefix;
            }
            result = labelPrefix + getSeparator() + revisionNumber;

            if (oldLabel.indexOf(result) > -1) {
                int lastSeparator = oldLabel.lastIndexOf(getSeparator());
                int firstSeparator = oldLabel.indexOf(getSeparator());
                int lastPart = 1;
                if (lastSeparator != firstSeparator) {
                    String suffix = oldLabel.substring(lastSeparator + 1);
                    lastPart = Integer.parseInt(suffix) + 1;
                }
                result += getSeparator() + lastPart;
            }
            LOG.debug("Incrementing label from " + oldLabel + " to " + result);
        } catch (IOException e) {
            LOG.error("could not execute svn binary", e);
        } catch (NumberFormatException e) {
            LOG.error("could not increment label. Old label was " + oldLabel + ". svn revision was " + revisionNumber,
                    e);
        }

        return result;
    }

    protected String getSvnRevision() throws IOException {
        String rev;
        Process p = null;
        try {
            p = Runtime.getRuntime().exec(new String[]{"svnversion", workingCopyPath});
            BufferedReader stdInput = new BufferedReader(new InputStreamReader(p.getInputStream()));
            rev = stdInput.readLine();
        } finally {
            if (p != null) {
                p.destroy();
            }
        }
        LOG.debug("SVN revision is: " + rev);
        return rev;
    }

    public boolean isValidLabel(String label) {
        // we don't mind what the previous label is,
        // when the next label is built, then parsing is performed to add / increment a suffix.
        return true;
    }

    public void setWorkingCopyPath(String path) {
        LOG.debug("Working Path is: " + path);
        workingCopyPath = path;
    }

    public String getLabelPrefix() {
        return this.labelPrefix;
    }

    public void setLabelPrefix(String labelPrefix) {
        this.labelPrefix = labelPrefix;
    }

    public String getDefaultLabel() {
        return getLabelPrefix() + getSeparator() + "0";
    }

    public String getSeparator() {
        return this.separator;
    }

    public void setSeparator(String separator) {
        this.separator = separator;
    }
}

Comparison

Some other Continuous Integration products, e.g. Cruise and Hudson, have much nicer web interface, while CruiseControl.NET and CruiseControl provides better flexibility and can be greatly customized. However, the flexibility sometimes means difficulty. For example, CruiseControl has three web sites – dashboard (:8080), project cruisecontrol (:8000), and JMS console – but not be seen on one page; CruiseControl supports CCNET CCTray but could not integrate with CCNET projects or dashboard (even if both developed by ThoughtWorks).

The build publisher supports using build label in both CCNET (by <labeller />) and CruiseControl (${label} in ant config). And in CCNET, the build publisher has to copy all contents in a specified source to another location although ant or nant can be used to customize such task. CruiseControl web interfaces do have a little more advanced features than CCNET. As an instance, the build target files (artifacts) can be published on CruiseControl dashboard so that can be downloaded. But the artifact in CCNET is just a local folder not accessible from the web.

On the other hand, CruiseControl does not display the runtime log on web interfaces. The build log can only be reviewed after the build is done. In CCNET dashboard, this is provided by a server log link. Although the server log in CCNET is not automatically updated (as nicely as a real time console display in Hudson), it at least gives user some hint before knowing the build succeeded or failed. Having better integration with Windows, CCNET can be run in either command line or service mode. For CruiseControl, you have to write a /etc/init.d/cruisecontrol.

Since CruiseControl.NET derived from CruiseControl, both work the same way and the cofiguration shares similarity. As open source projects, it is convenient to develop or modify plugin to suite need during implementation. CruiseControl is cross-platform by Java technology. CCNET has improved on web integration and preprocessor configuration so that project file can be well structured via nodeset expansion template.

Note: Source code samples are formatted by SyntaxHighlighter.

Ada puluhan project, ribuan file. Sama dengan sebuah mobil dengan ribuan komponen.

Dalam software development, segala sesuatunya menjadi lebih ribet. Apalagi dalam lingkungan yang koplingnya lepas. Lebih lengkap lagi deritanya, kita harus maintain ribuan library, yang masing2 punya versinya sendiri.

Berdasarkan tulisan Martin Fowler building saya bagi menjadi 3 tahap.

Tahap pertama, building dalam lingkungan CCNet. CCNet akan ngebuild dan dimasukkan kedalam folder build internal dia. Untuk ngebuild project berikutnya yang membutuhkan library dari hasil build project yang lain, CCNet akan menugaskan NAnt untuk mengambil dari folder build dan dimasukkan ke external-lib.

Tahap kedua, jika tahap pertama sukses, CCNet akan menugaskan NAnt untuk mengkopi hasil build–semuanya, ke folder build yang tershare untuk semua developer. Semua developer harus mengupdate library dia setiap kali run build project.

Tahap ketiga, secara manual, kita bisa meminta CCNet untuk build semua project dan dimasukkan ke folder build 3. Ditujukan untuk end-to-end testing. Bisa mungkin memanfaatkan Fit.

Tahap 1 dan 2 membutuhkan NAnt file build yang sama. Karena source eksternal buildnya berbeda–beda lokasi, mau tidak mau kita harus membuat satu property “Eksternal-lib-Source”. Alamat dari setiap folder berbeda untuk tiap komputer, jadi tidak perlu dikomit.

Been working with CruiseControl.Net to connect to our CMSynergy source control for some continous integration goodness. While configuring CCNet, I’ve had the oppurtunity to spend some more time with MSBuild - which always makes for some interesting times.

I plan on posting more info once this round is over, but I wanted to make a note about custom tasks from MSBuild. The setup for this, is that I am using a custom task to parse some input files based  on how the release is being defined – and then output the files that should be included in the final install package. Without going too much further into detail, the intial condition was that if this is a .0 release, all files are returned.
The task xml looked like:
<CustomTask SourceFiles=”@(SourceFiles)” Release=”$(ReleaseCondition)”>
<OutPut TaskParameter=”PublishFiles”  ItemName=”OutFiles”/>
</CustomTask>

The interesting bit to note here, was that just setting the output property to the input property (PublishFiles = SourceFiles) – ended up with the MetaData RecursiveDir on PublishFiles being reset  once the output was set to a new variable OutFiles. To get around this, I ended up setting a new custom metadata on the PublishFiles property that copies the RecursiveDir property from SourceFiles.

We won an award from CNET this week. Here’s the list of winners. Pictures to follow!

We finally had time to perform some much needed upgrades to the code base for the qualitative and quantitative metrics produced by our addin to CruiseControl.net continuous integration system

Anyway here’s an idea of how the framework API is shaping up. Expect this to move dramatically toward’s Fowler’s fantastic coverage of ‘Expression Builder’.

We hope that this will evolve into a full Linq provider, and due to the XML foundation this is not all that unrealistic a goal.
 

namespace CCStatisticsTDD
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using CCStatistics.Domain.Api;
    using CCStatistics.Domain.Api.Interfaces;
    using NUnit.Framework;
    using Rhino.Mocks;
    using TDDViewOutputStatus;
    using ThoughtWorks.CruiseControl.Core;

    /// <summary>
    /// This is a monolitic 'Smoke Test'. There are many fine grained tests to be writtem!
    /// </summary>
    [TestFixture]
    public class MainTestFixtureBaselineSmokes : TestBase
    {
        /// <summary>
        /// Gets the mock list.
        /// </summary>
        /// <param name="mockBuildName">Name of the mock build.</param>
        /// <param name="repositoryBuildCount">The repository build count.</param>
        /// <returns></returns>
        /// Documentation Created 6/23/2008
        private static List<string> GetMockList(string mockBuildName, int repositoryBuildCount)
        {
            // Add the build name to the array tht is expected to be available for ALL builds
            // from the repositoy. Here we use 10

            return
                Enumerable.Repeat(mockBuildName + " {0}", repositoryBuildCount).Select(
                    s => String.Format(s, DateTime.Now.TimeOfDay.TotalMilliseconds/1000)).ToList();
        }

        protected override ICCStatsProject Prepare()
        {
            // We need a name for this project
            const String mockBuildName = "CCStatisticsBuildMock";

            // Simulate 100 legacy build results
            const int repositoryBuildCount = 100;

            var repository = mocks.Stub<IIntegrationRepository>();
            var buildNames = GetMockList(mockBuildName, repositoryBuildCount);

            // OK set this up to return our builds
            repository.Stub(x => x.GetBuildNames()).Return(buildNames.ToArray());

            var currentProject = mocks.Stub<ICCStatsProject>();

            currentProject.Stub(x => x.IntegrationRepository).Return(repository);
            currentProject.Stub(x => x.StatisticsForPublisher).Return(MockStats);

            currentProject.StubEx(x => x.Name, mockBuildName).
                StubEx(x => x.BuildLogDirectory, DefaultDirectory).
                StubEx(x => x.ArtifactDirectory, DefaultDirectory).
                StubEx(x => x.WorkingDirectory, DefaultDirectory).
                Stub(x => x.StatsPostPublisher).Return(InitializePublisher(currentProject));

            return currentProject;
        }

        private IMetricPublisher InitializePublisher(ICCStatsProject project)
        {
            // OK now it's interesting.. We have our own IMetricPublisher which is a stand-in for the
            // StattisticsPublisher concrete class in CruiseControl. We need to add a new overload
            // and obviously make this behave in ways it was not intended to (as we are doing all the legacy builds)
            var _statisticsPublisher = mocks.Stub<IMetricPublisher>();

            // Here we use the mock array of stats created above. This is a duplicate of StatisticsForPublisher
            // Need to look into consolodating that.
            _statisticsPublisher.Stub(x => x.ConfiguredStatistics).Return(MockStats);

            // Core Validation is Below
            _statisticsPublisher.Expect(x => x.ProcesLogFile(project.Name)).
                IgnoreArguments().Repeat.Times(project.BuildCount);

            return _statisticsPublisher;
        }

        /// <summary>
        /// NOTE: This is a FULL CYCLE Mock Smoke test. We need many more finely grained
        /// tests. This is just to ensure all is well in the application. Each subcomponent
        /// will need to have tests added as this evolves. In the mean time this works
        /// well to ensure we fundamentally work and this is called from OUR BuildServer
        /// (how META is that?) to ensure this is working.
        /// This should be your first stop to undersand this code
        /// </summary>
        [Test]
        public void ShouldSmokeTestProjectAPI()
        {
            using (mocks.Record())
                Assert.IsTrue(ForStatistics.RefreshValues(MockTDDView.New, Prepare()));
        }
    }

    public static class MockExtensions
    {
        /// <summary>
        /// Stubs the type defined
        /// </summary>
        /// <typeparam name="TType">The type of the type.</typeparam>
        /// <param name="currentProject">The current project.</param>
        /// <param name="funcMock">The func mock.</param>
        /// <param name="returnString">The return string.</param>
        /// <returns></returns>
        /// Documentation Created 6/20/2008
        public static TType StubEx<TType>(this TType currentProject, Func<TType, String> funcMock,
                                          String returnString)
            where TType : class, ICCStatsProject
        {
            currentProject.Expect(funcMock).Return(returnString).Repeat.Any();
            return currentProject;
        }
    }
}

1. Introduction (part 1)
2. Resources (part 1)
3. Installation (part 1)
3.1. Install CruiseControl.NET (part 1)
3.2. Create a CCNet Website in IIS (part 1)
3.3. Install Nunit (part 1)
4. CruiseControl.NET Server Configuration – General (part 1)
5. Structure of a ‘Project’ Configuration File (part 1)
6. Source Control Block (part 1)
7. Trigger Block (part 1)
8. Labeller Block (part 1)
9. Tasks Block
10. MsBuild Task
10.1. MSBuild and ReferencePath – CruiseControl.NET not resolving reference to Nunit
10.2. An Alternative MSBuild Logger – Christian Rodemeyer’s MsBuildToCCNet
10.3. CruiseControl.NET Webdashboard fails in finding images if not installed in virtual directory
10.4. MSBuildToCCNET reports wrong number of compiled projects
10.5. CruiseControl.NET, MsBuild Task and Resources – Assembly Linker
10.6. CruiseControl.NET, MsBuild Task and Web Application projects
11. Nunit Task
11.1. Nunit Task
11.2. Executable Task
12. Publishers Block
13. PreBuild Block
13.1. Install Nant
13.2. Nant Fundamentals

This article is the second one of a series dedicated to CruiseControl.Net.
In the first part (which you can find here) we installed it and had an overview of how to configure it.
Then we started to configure a project file: we instructed the Source Control Block to use Subversion, the Trigger Block to check it periodically and the Labeller Block to use: svnRevisionLabeller
In this second article we will see the Tasks Block and I will point out some issues that might arise and provide solutions as well.

Thanks to Frank Geerlings for making me aware of a casing problem with the xml samples.
By talking with WordPress support it came out that there was a little bug and they suggested me
how to fix the problem.

9. Tasks Block

The tasks block represents how the build of the project actually takes place.
In our example we will use an MsBuild Task to accomplish the main purpose of our project, which is to compile the versioned Visual Studio solution.
After that we will use an Executable Task to run our unit tests, if the build succeeds.
Let’s see the whole Tasks Block, at first:

<tasks>
<!-- compiles working copy -- >
  <msbuild>
    <executable>C:\WINDOWS\Microsoft.NET\Framework\
      v2.0.50727\MSBuild.exe
    </executable>
    <workingDirectory>C:\develop\CCnet\project1WorkingDir
    </workingDirectory>
<projectFile>DummySolution.sln</projectFile >
    <buildArgs>/noconsolelogger /v:quiet
      /p:Configuration=Debug
      /p:ReferencePath="C:\Program Files\NUnit 2.4.7\bin"
    </buildArgs>
    <targets>ReBuild</targets >
    <timeout>600</timeout >
    <logger>c:\Program Files\CruiseControl.NET\server\
      Rodemeyer.MsBuildToCCNet.dll</logger >
  </msbuild>
<!-- launches nunit tests on working copy -- >
  <exec>
    <executable>C:\Program Files\NUnit 2.4.7\
      bin\nunit-console.exe
    </executable >
    <buildArgs>/xml:..\project1CCnetArtifacts\nunit-results.xml
      /nologo Dummy.sln.nunit
      /exclude:LongRunning,AnotherCategoryName
    </buildArgs>
  </exec>
</tasks>

Let’s focus on the MsBuild Task first and see how we can configure and customize it:

→ top of post
→ top of paragraph

10. MsBuild Task

Let’s have a look at the meaning of the xml nodes children of the <msbuild> node:

<executable>: contains the path to the msbuild executable file. You don’t really need to set it because the default value is the standard installation path: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe.
I decided to set it explicitly just to be sure about it .
<workingDirectory>: is the directory in which MsBuild will be run, so it must be the directory containing our project’s checked out working copy. You can provide a path relative to the current project’s workinDirectory but I preferred to provide the full path. Actually, the path to the CCNET checked out working copy is the same as the <workingDirectory> field of the Source Control Block.
<projectFile>: is the name of the project to build. MsBuild accepts a Visual Studio solution file as the project file to build. Obviously the MsBuild Task accepts it as well.
<buildArgs> This row provides additional command line arguments to MsBuild. We tell it not to log events to the console (/noconsolelogger), to build the Debug configuration (/p:Configuration=Debug) and to provide a reduced output (/v:quiet).
As far as the /p:ReferencePath buildArg is concerned it is worth to talk extensively about a problem that could arise with Nunit, so have a look at paragraph 10.1.

10.1 MSBuild and ReferencePath – CruiseControl.NET not resolving reference to Nunit

It could happen that CCNET is not able to locate Nunit (or some other dependency assembly) depending on how your project file has been created by Visual Studio.
Open your project file (DummyProject.csproj) with a text editor (e.g.: Notepad++). If you find an entry as follows in it:

<Itemgroup>
  <Reference Include="nunit.framework, Version=2.4.7.0,
    Culture=neutral, PublicKeyToken=96d09a1eb7f44a77,
    processorArchitecture=MSIL" />
      ....
</Itemgroup>

with no <HintPath> associated to the Nunit <Reference> it could be that CCNET will not be able to resolve that reference if you don’t register nunit.framework.dll in the server’s GAC.

You can make sure that CCNET is able to resolve the dependency by providing an alternative search path in which to look for.
Each assembly referenced in the Visual Studio project file needs to be located by MSBUild at compile time.
The location of the referenced assemblies is resolved by MSBuild by looking in several locations in a particular search order (as explained here).
We could modify the .csproj file by providing a value as a child node of the node, e.g.:

<Reference Include="DummyLibrary, Version=1.0.0.0,
    Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\CommonReferencedDLLs\DummyLibrary.dll
  </HintPath>
</Reference>

This approach has two drawbacks:

1. the hintpath is a relative path, thus making the build success depend on the location of the project relative to the referenced assembly (this could be a problem if we reference an external assembly);
2. we need to modify each Visual Studio project file by hand and we don’t want to do it!

Fortunately there’s an easy way out:
We can override all the project specific settings for path resolving by passing a ReferencePath property from the MSBuild command line.
Such property accepts as value a list of paths (MSBuild DummySolution.sln /p:”ReferencePath=<Path1;Path2;Path3>”) and it is checked by the build process before checking other locations (HintPath for example).
So the way to provide an alternative search path from the command line is to pass as argument a ReferencePath property.
This is the reason why the command line provided in the <buildArgs> field contains the ReferencePath property pointing to the Nunit install path:
/p:ReferencePath=”C:\Program Files\NUnit 2.4.7\bin”.

→ top of post
→ top of paragraph

end of paragraph 10.1
continues paragraph 10. MsBuild Task

Let’s go on with the analysis of the xml nodes children of the <msbuild> node:
<targets> specifies which targets to build in this msbuild project file. It represents the MSbuild’s /target command line argument. We set it to Rebuild (clean and build).
<timeout> is the number of seconds before assuming that the process has hung. If timeout is exceeded the process will be killed.
<logger> specifies the path to the assembly containing the logger to use to format the log output of MSbuild .
If you don’t want to use the alternative logger that I used in the configuration shown above, you can rely on the default logger as explained here and skip the following
paragraph 10.2.
To use the default logger:

• leave out the <logger> field,
• download the assembly containing the default xml logger here (find info here),
• copy the downloaded assembly (ThoughtWorks.CruiseControl.MSBuild.dll) to the folder: C:\%ProgramFiles%\CruiseControl.NET\server.

I suggest to use the alternative logger (by Christian Rodemeyer) as explained in the following paragraph. The RodeMeyer’s logger provide lighter msbuild output and his modified stylesheets provide much more readable display of such information.

10.2. An Alternative MSBuild Logger – Christian Rodemeyer’s MsBuildToCCNet

I chose to use a logger alternative to the default one: Christian Rodemeyer’s MsBuildToCCNet.
You can find it at: Improved MSBuild Integration. From there either you can download separately the assembly and all related stuff needed to correctly display the results from Rodemeyer’s logger or you can download a zip file with the whole project and source code.

In the page cited above you can find detailed instructions on how the logger works and how it should be configured.
In the current paragraph I’ll illustrate the installation process and add some useful tips for making it work.
I suggest to download the full project that comes in a zip file named: MsBuildToCCNet.zip (download here).
Unzipping the package you will have a directory named: MsBuildToCCNet. Inside this directory you will find, among the rest, a directory named Release, containing the assembly: Rodemeyer.MsBuildToCCnet.dll.
Just copy the assembly to the \CruiseControl.NET\server folder (e.g.: c:\Program Files\CruiseControl.NET\server\).
There’s another subdirectory of the MsBuildToCCNet folder, named ccnet where you can find the resources needed to correctly display the logs produced by Rodemeyer’s logger. Those resources are:
cruisecontrol.css and
msbuild2ccnet.xsl.

You need to use those two files and to configure the Webdshboard:

1. Move into your CruiseControl.NET Webdashboard folder, under the path: C:\%ProgramFiles%\CruiseControl.NET\webdashboard (e.g.: c:\Program Files\CruiseControl.NET\webdashboard\) and back up the file: cruisecontrol.css.
   Then replace it with the cruisecontrol.css file you found in the Rodemeyer’s MsBuildToCCNet folder (e.g.: copy MsBuildToCCNet\ccnet\cruisecontrol.css to c:\Program Files\CruiseControl.NET\webdashboard\cruisecontrol.css);
2. There’s a subdirectory of the CruiseControl.NET Webdashboard folder, named: xsl.
   You need to copy the other resource (msbuild2ccnet.xsl) you found in the MsBuildToCCNet\ccnet folder in that directory: C:\%ProgramFiles%\CruiseControl.NET\webdashboard\xsl\;
3. You need to modify the dashboard.config file in the CruiseControl.NET Webdashboard folder in order to correctly show the output of the logger.
   Being that we’re talking about the Webdashboard configuration I will show you all the changes you will need to do to let it work with the following three components (even if we’ll see two of them only in the following paragraphs):
   • MsBuildToCCNet
   • Nunit integration
   • FxCop integration

   First of all choose a 32 x 32 jpg image representing a smiling icon and place it in the CruiseControl.NET Webdashboard folder: C:\%ProgramFiles%\CruiseControl.NET\webdashboard.
   Rename the image file: your_happy_image.jpg and, when a new build succeeds, you’ll obtain a smiling icon in the Webdashboard report! (you can find a sample image here).
   Then open CruiseControl.NET\webdashboard\xsl\msbuild2ccnet.xsl and go to line 24:

   <xsl :if test="@error_count = 0 and @warning_count = 0">
   <tr>
   <td><img src="/ccnet/your_happy_image.jpg"
              alt="Happy Image  " /> Juchuu !!!</td>
   </tr>
   </xsl>
   

   replace the img src attribute: /ccnet/your_happy_image.jpg with /your_happy_image.jpg if you configured iis with a new website for the webdashboard instead of a virtual directory. If you’re usign the default virtual directory named ccnet, don’t modify that row.
   Next you need to locate the field: <buildPlugins> in C:\%ProgramFiles%\CruiseControl.NET\webdashboard\dashboard.config and arrange or delete its children nodes in order to obtain the following configuration (remember to back up the file first):

   <buildplugins>
     <buildreportbuildplugin>
       <xslfilenames>
         <xslfile>xsl\header.xsl</xslfile>
         <xslfile>xsl\modifications.xsl</xslfile>
         <xslfile>xsl\msbuild2ccnet.xsl</xslfile>
         <xslfile>xsl\unittests.xsl</xslfile>
         <xslfile>xsl\compile.xsl</xslfile>
         <xslfile>xsl\fxcop-summary.xsl</xslfile>
       </xslfilenames>
     </buildreportbuildplugin>
     <buildlogbuildplugin />
     <xslreportbuildplugin description="NUnit Details"
          actionName="NUnitDetailsBuildReport"
          xslFileName="xsl\tests.xsl" />
     <xslreportbuildplugin description="NUnit Timings"
          actionName="NUnitTimingsBuildReport"
          xslFileName="xsl\timing.xsl" />
      <xslreportbuildplugin description="FxCop Report"
          actionName="FxCopBuildReport"
          xslFileName="xsl\FxCopReport.xsl" />
   </buildplugins>
   

   As you can see, such configuration includes also stylesheet files for nunit and fxcop integration. We will soon configure the server to integrate those components.

→ top of post
→ top of paragraph

end of paragraph 10.2
continues paragraph 10. MsBuild Task

While adding the smiling image in the previous paragraph we had to change the path in the xsl file.
The same problem could arise with other stylesheet files if you configured the webdashboard to be a website instead that a virtual directory named ccnet.
Have a look at the next paragraph for details:

10.3. CruiseControl.NET Webdashboard Fails in Finding Images if Not Installed in Virtual Directory

If you unchecked ‘Create virtual directory in IIS for Web dashboard’ as shown in part 1 of this tutorial at 3.1. Install CruiseControl.NET and installed the Webdashboard as a new website as shown in the paragraph: 3.2. Create a CCNet Website in IIS, the webdashboard could have problems in resolving image paths.
You will realize it as soon as you will configure the server to integrate nunit or fxcop (will see it in following paragraphs).
To make sure not to have this problems you must modify the following files:
xsl\tests.xsl
xsl\fxcop-summary.xsl
under: C:\%ProgramFiles%\CruiseControl.NET\webdashboard\

you have to replace all the paths relative to the root of the website with relative paths, e.g:

in the file: xsl\tests.xsl you should replace all entries like:

eImg.src = "<xsl :value-of select="$applicationPath"/>/images/arrow_minus_small.gif";

with:

eImg.src = "<xsl :value-of select="$applicationPath"/>images/arrow_minus_small.gif";

and entries like:

<img src="{$applicationPath}/images/fxcop-error.gif"/>

with:

<img src="{$applicationPath}images/fxcop-error.gif"/>

that is, you simply need to delete the leading ‘forward slash’ at the beginning of the path (just before the ‘images’ folder name).

you need to accomplish the same task with the file xsl\fxcop-summary.xsl, e.g.:

you should replace entries like:

<xsl :attribute name="src"><xsl :value-of select="$applicationPath" />/images/fxcop-critical-error.gif</xsl>

with:

<xsl :attribute name="src"><xsl :value-of select="$applicationPath" />images/fxcop-critical-error.gif</xsl>

Actually, you should find all paths to images in those two files and delete the leading forward slash.

→ top of post
→ top of paragraph

end of paragraph 10.3
continues paragraph 10. MsBuild Task

Back to the MSBuildToCCNET alternative Logger for MsBuild, I will explain now why I decided to recompile the source code instead of using the assembly provided: MsBuildToCCNet\Release\Rodemeyer.MsBuildToCCnet.dll

10.4. MSBuildToCCNET Reports Wrong Number of Compiled Projects

I found that MsBuildToCCNet reported the wrong number of projects in the webdashboard in the page reporting the details of the last build.
There’s a row that sounds like the following, displaied in that page:

‘15 Projects built with 2 warnings’

Looking at the source code (in the file: Logger.cs) I realized that the list of Project type instances includes the solution file (DummySolution.sln) and a Project object named “MSBuild“, somehow representing the MsBuild process.
Appearently this is the reason why the reported number of projects is wrong.
I still haven’t tried to contact the author so I don’t know very well how the Logger is supposed to work as far as this count is concerned.
As a workaround I modified the following row:

w.WriteAttributeString("project_count",
                     XmlConvert.ToString(projects.Count));

turning it into:

w.WriteAttributeString("project_count",
                     XmlConvert.ToString(projects.Count - 2));

in the ‘WriteLog(XmlWriter w)’ method (file: Logger.cs at row 104).

This seems having fixed the problem with no side effects.

→ top of post
→ top of paragraph

end of paragraph 10.4
continues paragraph 10. MsBuild Task

You could have problems running msbuild task if your server machine (the one in which you installed CruiseControl.NET) is not updated with all the software installed in a developer workstation. Let’s see which problems could arise:

10.5. CruiseControl.NET, MsBuild Task and Resources – Assembly Linker

If you want to provide localization for any of your projects or somehow use resources files (.resx) you will get an error during the build on the CruiseControl.NET server if MsBuild is not able to locate the Assembly Linker.
The error should look something like:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1950,9): error MSB3011: “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\AL.exe” was not found. Either 1) Install the .NET Framework SDK, which will install AL.exe. Or 2) Pass the correct location of AL.exe into the “ToolPath” parameter of the AL task.

AL.exe is used to produce the satellite assemblies and the executable file is placed in the .NET framework directory.
But Al.exe is a .Net Framework SDK tool. It is not included in .Net Framework 2.0 runtime installation.
You need to install the .NET framework SDK on the server machine if you don’t want to encounter this problem.
If you want to solve this particular issue in a tricky way without installing the whole SDK, you can copy al.exe.config e al.exe from a developer workstation and place them in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory on the server machine.
This is how I solved the problem but I suggest you to install the .NET framework SDK on the server machine.

→ top of post
→ top of paragraph

10.6. CruiseControl.NET, MsBuild Task and Web Application projects

A particular note is due for Web projects.
Updating Visual Studio 2005 you get the SP1. Together with the Service Pack 1 for Visual Studio you get the WebApplication project template.
Such template lets us add a new kind of project to our solution: a web site project structured exactly like any other Visual Studio project.
So you can quit creating new websites (File –> New –> Web Site…) and start creating new WebApplication projects (File –> New –> Project… and then choose ‘ASP.NET Web Application‘).

In order to use WebApplication projects you need to have Visual Studio installed on your machine and the WebApplication project plugin (that comes with the Visual Studio 2005 SP1).
If the server in which CruiseControl.NET server is running is not a develpment workstation you will get an error when trying to build a WebApplication project, beacuse you miss those two prerequisites.

You can easily fix this problem: you simply need to copy the file: Microsoft.WebApplication.targets that you can find under:
“C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\”
from a development workstation and paste it to the corresponding path on the server machine (creating the directories in the path if needed).

Additionally, if you’re using an ASP.NET AJAX Enabled WebApplication as the web project template you need to install the aspnet-ajax extensions as well.
You can find the installer (ASPAJAXExtSetup.msi) for .NET framework 2.0 here

→ top of post
→ top of paragraph

11. Nunit Task

The second Task Block that you find in the xml fragment above is an Executable Task used to instruct CruiseControl.NET to run unit tests with Nunit.

At first I tried to use a Nunit Task Block but I soon realized that it was not good for me because it was not possible to provide arguments to the task that should be used as arguments of the Nunit command-line executable.

This is a problem because there’s no way to let the Nunit task be aware of Nunit categories.
For those who don’t know, Nunit lets you specify a ‘Category‘ attribute in test methods, with the following syntax:

[Test]
[Category("LongRunning")]
public void VeryLongTest()
{ /* ... */ }

This attribute allows you to instruct Nunit to treat all the methods belonging to the same category in the same way.
Usually what we want to do is to exclude a cluster of tests from running.
Typically we exclude tests that take too much to run, using the following syntax with the nunit command-line tool:

nunit-console.exe /exclude:LongRunning,AnotherCategoryName

You can configure excluded categories in nunit GUI as well, by clicking the ‘Categories‘ tab in the top left corner.
A list of available categories will be shown. Just select the categories of interest and click the Add button.
Then check the Exclude these categories checkbox at the bottom of the page and run the nunit project.

It is very useful to be able to exclude some categories of tests from the continuous integration environment, still being able to run them on developer machines.

This is the reason why I recently submitted a patch to CruiseControl.Net adding support for Nunit categories.
It’s not included in the official release yet, because I submitted it too late for this purpose.
However you can find it in the current build which is publicly available at: ccnetlive. The patch is included starting from build: 3591.
So now you have two chances to use categories:

1. If you really want to use the last officially released version, read the paragraph 11.2 about how to use an Executable Task (the method described can be useful also if you want to use any other unsupported Nunit command line argument);
2. Instead if you can download the latest build from ccnetlive you will be able to specify categories inside the Nunit Task block, as explained in paragraph 11.1

11.1. Nunit Task

If you downloaded the most recent build and followed the installation instructions (see: 3. Installation) you can go on reading this paragraph.
If you installed the official release or a build older than 1.4.0.3591, you can still modify your installation with the following instructions:

download the zipped package (here) or source code. Unzip it in a temporary directory and locate the assembly: ThoughtWorks.CruiseControl.Core.dll (which, for the zip package, is in the directory: ’server’).
Copy and replace it to the original one in your CCNET installation directory (back up the original one first) that should be: Program Files\CruiseControl.NET\server.

That’s it! Now you can use the CruiseControl.NET’s Nunit Task Block also for specifying Nunit categories (see: Nunit categories for reference).

It is possible to specify a list of the categories of tests that we want to be excluded.
It is possible, as well, to specify a list of the only categories that we want to be included as allowed by the Nunit Command-line or GUI interface.
The configuration syntax for the Nunit task becomes:

<nunit>
<path>C:\Program Files\NUnit 2.4.7\bin\nunit-console.exe
</path>
    <assemblies>
        <assembly>Dummy.sln.nunit</assembly>
    </assemblies>
    <excludedCategories>
        <excludedCategory>LongRunning</excludedCategory>
	<excludedCategory>Category 2</excludedCategory>
    </excludedCategories>
</nunit>

for excluded categories, or:

<nunit>
<path>C:\Program Files\NUnit 2.4.7\bin\nunit-console.exe
</path>
    <assemblies>
        <assembly>Dummy.sln.nunit</assembly>
    </assemblies>
    <includedCategories>
        <includedCategory>LongRunning</includedCategory>
	<includedCategory>Category 2</includedCategory>
    </includedCategories>
</nunit>

for included categories. You can find the official reference at this page on the official website.

The Nunit task output log file is automatically integrated in the CCNET build results.
So you don’t need to specify the Merge task (needed if you use the procedure explaine in paragraph 11.2 instead of this one) in the Publishers block as explained in paragraph 12:

<merge>
  <files>
    <file>..\project1CCnetArtifacts\nunit-results.xml</file>
  </files>
</merge>

Instead you still need to delete the previous Nunit log file before each build process as explained in the paragraph 13 – PreBuild Block.

→ top of post
→ top of paragraph

11.2. Executable Task

If you’re working with the official release of CruiseControl.Net (release 1.4) Nunit Task Block syntax only allows you to specify the target solution and little more. In our example it would be:

<nunit>
<path>C:\Program Files\NUnit 2.4.7\bin\nunit-console.exe
</path>
	<assemblies>
		<assembly>Dummy.sln.nunit</assembly>
	</assemblies>
</nunit>

where Dummy.sln.nunit is the Nunit project file for our solution.

The solution I strongly suggest is to replace the Nunit Task with an Executable Task like the one shown below:

<exec>
  <executable>
    C:\Program Files\NUnit 2.4.7\bin\nunit-console.exe
  </executable>
  <buildArgs>/xml:..\project1CCnetArtifacts\nunit-results.xml
    /nologo Dummy.sln.nunit
    /exclude:LongRunning,AnotherCategoryName
  </buildArgs>
</exec>

You only need to specify the full path to the Nunit command-line executable file in the <executable> field and the command-line arguments in the <buildArgs> field.

In the <buildArgs> field you specify arguments as if provided directly to nunit-console.exe:

1. specify the path to the file in which nunit will write its output: /xml:..\project1CCnetArtifacts\nunit-results.xml.
   The file should be produced in the artifactDirectory of the current CCNET project.
   By default the executable run by an executable task is run in the Project Working Directory, so the path to the output file is relative to such directory.
2. You can pass many things as Nunit targets (assemblies, Visual Studio projects or Nunit project files). I suggest to create an Nunit project and pass it as argument to nunit-console.exe as shown in the sample above (where the nunit project file is called: Dummy.sln.nunit).
3. you can then add: /exclude:LongRunning,AnotherCategoryName thus excluding unwanted tests.

Specifying the name of the output file is not enough.
In order to make the output written by nunit in the file nunit-results.xml (arbitrary name specified in the buildArgs tag), available to CruiseControl.NET we need to use a File Merge Task.
If we used Nunit task the output file would have been automatically merged with other output for CruiseControl.NET.
Using the Executable Task we need to explicitly configure CruiseControl.NET to merge the Nunit output file in the log file parsed by CruiseControl.NET.
We will tell CruiseControl.NET to do it at the end of the build process, namely in the Publishers section.

→ top of post
→ top of paragraph

12. Publishers Block

We will add a File Merge Task at the beginning of the Publishers section. You can see below the publishers section as it is defined in our project configuration file:

<publishers>
  <merge>
    <files>
      <file>..\project1CCnetArtifacts\nunit-results.xml
      </file>
    </files>
  </merge>
  <xmllogger />
  <statistics />
  <modificationHistory onlyLogWhenChangesFound="true" />
  <artifactcleanup cleanUpMethod="KeepLastXBuilds"
    cleanUpValue="20" />
      ...
</publishers>

The File Merge Task specifies the paths to the files that we want to be merged by the Xml Log Publisher Task with the rest of its own output (you don’t need to specify nunit output file if you used the Nunit Task as in paragraph 11.1. Nunit Task).
All of this output is placed by default in the buildlogs directory under the Project’s Artifact Directory.
So the File Merge Task should appear before the Xml Log Publisher Task in the publishers section.
The Xml Log Publisher Task (‘xmllogger‘) is needed for making the web dashboard work correctly.
The ‘statistics‘ field collects and updates statistics for each build. You can see them clicking: View Statistics on the left side of the Web Dashboard.
The ‘modificationHistory‘ field logs all the modifications for each build. With onlyLogWhenChangesFound you can choose to log info only for builds happened when changes take place (not for forced builds). You can see the modification history by clicking: View Modification History on the left side of the Web Dashboard.

I then added an ‘artifactcleanup‘ field in order to keep memory of the last 20 builds only.
This task allows us to choose between two clean up modes of the past build logs:
- deleting logs older than a specified number of days
- keeping only a specified number of logs: the more recent ones (cleanUpMethod=”KeepLastXBuilds”)

In the sample above we typed the second choice specifying 20 as cleanUpValue thus telling CruiseControl.NET to keep the log files for the last 20 builds only.

→ top of post
→ top of paragraph

13. PreBuild Block

There’s another issue to solve when integrating Nunit using either an Exec Task or the Nunit Task: the Nunit log file is not deleted after the build succeeds or fails.
So upon the next build we’ll still have the old Nunit log file until the Task running Nunit is executed.
To understand what I’m going to explain now, keep in mind that if a task in the Tasks Block fails all the subsequent tasks in the block will be skipped while the tasks in the Publishers Block will be executed.

If, during the next build, the MSBuild Task fails, the Exec Task (Nunit Task) launching Nunit isn’t executed at all so the File Merge Task will merge the previous Nunit log file with the current Xml Log Publisher output, thus leading to an incorrect report: still displaying the Nunit results relative to the previous build.
We would obtain the current MSBuild report but the old Nunit report.
This behavior can lead to misunderstanding of the results so it is a good practice to delete the old Nunit log file before every new build takes place.

The place to accomplish this task is the PreBuild Block.
I used a Nant build file to drive the steps needed to obtain the desired result (simply delete a file if it exists).

13.1. Install Nant

You need to install the Nant Build tool on the server machine.
Just download the zip package: nant-0.85-bin.zip from here and unzip it into the folder: C:\Program Files\Nant.

13.2. Nant Fundamentals

Nant is a build tool driven by xml configuration files (Nant build files).
When you call nant.exe from the command line and you don’t specify a build file (you can specify one passing as argument: -buildfile:pathToDir\FileName.build) NAnt looks for a file ending with .build (e.g.: NAnt.build) in the current directory. If it finds such file, it uses it as the reference for the tasks to execute.

The file structure is shown in the following sample xml file:

< ?xml version="1.0"?>
<project name="dummy" default="target1" basedir=".">
	<description>dummy project</description>
	<target name="target1" description="target1 description">
	    ... (a list of Nant tasks will be placed here)
	</target>
	<target name="target2" description="target2 description">
		<delete file="pathToFile\FileName"
                failonerror="false" />
		... (a list of other Nant tasks will be placed here)
	</target>
</project>

A build file contains one <project> field with one or more children <target> fields each containing different Nant tasks (e.g.: the <delete> task).
When invoking nant.exe you can specify the name of the target to be executed and Nant will execute all the tasks contained in that target. If you don’t provide a target, the default one will be executed (i.e. the one specified in the ‘default‘ attribute of the <project> field).

end of paragraph 13.2
continues paragraph 13. PreBuild Block

Once you’ve got Nant installed on the server machine you have to create a file named nant.build and place it, for convenience, in the directory in which you placed all the CruiseControl.NET related stuff (in this example: C:\develop\CCnet).

At the moment we need just one target to delete Nunit log files. Later we will add another target.
The actual file content is the following:

< ?xml version="1.0"?>
<project name="Dummy" default="cleanNunit" basedir=".">
  <description>CCNET Tasks</description>
  <target name="cleanNunit"
         description="removes nunit log file">
    <delete file="${CCNetArtifactDirectory}\nunit-results.xml"
          failonerror="false" />
  </target>
</project>

When we tell Nant to execute the ‘cleanNunit‘ target, the delete task will be executed and the nunit-results.xml file will be deleted.
We use one of the environment variables provided by CCNET to retrieve the path to the artifact directory: ${CCNetArtifactDirectory} so this Nant build file will only work when run from CruiseControl.NET.

In the Prebuild Block we will instruct CruiseControl.NET to run a Nant task by adding a CruiseControl.NET Nant Task Block.
Such block lets us instruct CruiseControl.NET to execute Nant and lets us specify a Nant build file and the list of Nant targets to execute.
Remember that we named the build file: nant.build and we placed it in the directory: C:\develop\CCnet.
Now we provide this information to the CruiseControl.NET Nant Task Block as shown in the following example:

<prebuild>
<!-- clean nunit output to avoid CCNET reporting
       about previous build tests if current build fails -->
  <nant>
    <executable>C:\Program Filse\Nant\bin\nant.exe
    </executable>
    <baseDirectory>C:\develop\CCnet</baseDirectory>
    <nologo>false</nologo>
    <buildFile>nant.build</buildFile>
    <targetList>
      <target>cleanNunit</target>
    </targetList>
  </nant>
</prebuild>

the <executable> field specifies the path to the version of nant.exe you want to run,
the <baseDirectory> specifies the directory to run the NAnt process in,
<nologo> passes the -nologo argument to the Nant command line,
<buildFile> specifies the path to the build file to use (relative to the <baseDirectory>),
<targetList> is used to specify a list of targets, each one in a <target> field.

Now we can be sure that each build has the Nunit log file deleted before being executed.

→ top of post
→ top of paragraph

<< CruiseControl.Net Tutorial – Part 1

As soon as possible I will post the third and last part of this tutorial

1. Introduction
2. Resources
3. Installation
3.1. Install CruiseControl.NET
3.2. Create a CCNet Website in IIS
3.3. Install Nunit
4. CruiseControl.NET Server Configuration – General
5. Structure of a ‘Project’ Configuration File
6. Source Control Block
7. Trigger Block
8. Labeller Block
9. Tasks Block (part 2)
10. MsBuild Task (part 2)
10.1. MSBuild and ReferencePath – CruiseControl.NET not resolving reference to Nunit (part 2)
10.2. An Alternative MSBuild Logger – Christian Rodemeyer’s MsBuildToCCNet (part 2)
10.3. CruiseControl.NET Webdashboard fails in finding images if not installed in virtual directory (part 2)
10.4. MSBuildToCCNET reports wrong number of compiled projects (part 2)
10.5. CruiseControl.NET, MsBuild Task and Resources – Assembly Linker (part 2)
10.6. CruiseControl.NET, MsBuild Task and Web Application projects (part 2)
11. Nunit Task (part 2)
11.1. Nunit Task (part 2)
11.2. Executable Task (part 2)
12. Publishers Block (part 2)
13. PreBuild Block (part 2)
13.1. Install Nant (part 2)
13.2. Nant Fundamentals (part 2)

1. Introduction

In this article series I will review the various steps needed to setup and configure a working CruiseControl.Net server.
The goal is to set up a Continuous Integration process for a sample project as close as possible to a real-life project.
I will point out several issues that might arise and I will provide solutions as well.
I will try to underline all the details that you need to be aware of.

Thanks to Frank Geerlings for making me aware of a casing problem with the xml samples.
By talking with WordPress support it came out that there was a little bug and they suggested me
how to fix the problem.

→ top of post

2. Resources

During the article I will guide you through the installation process of the following software:

Subversion
CruiseControl.NET
Nunit

Nant
FxCop
NantContrib

The following are optional:

TortoiseSVN
AnkhSVN

You can find information about how to install: Subversion, TortoiseSVN and AnkhSVN in the article: Guide to Versioning a Visual Studio Solution with Subversion, TortoiseSVN and AnkhSVN.
There you can also find a quick guide about how to create a Subversion repository and how to add a Visual Studio solution to source control.

This tutorial assumes that you have Subversion 1.4.6 installed and that you have configured a Subversion repository at the url: svn://localhost/trunk as shown in the article: Guide to Versioning a Visual Studio Solution with Subversion, TortoiseSVN and AnkhSVN.

If you already have a working environment with a repository and versioned files, you can go on reading and replace the paths and names in the examples with the paths and names in your environment.

→ top of post
→ top of paragraph

3. Installation

• 3.1. Install CruiseControl.NET
• 3.2. Create a CCNet Website in IIS
• 3.3. Install Nunit

This tutorial will assume that you install CruiseControl.NET on the same machine on which you had installed the Subversion repository. So, first of all, let’s go through the steps needed to install CruiseControl.NET on your server machine.

3.1. Install CruiseControl.NET

Download the latest CruiseControl.NET release from: SourceForge or the latest build from CCNetLive.
You can find release notes here. For this article I used the installer for version 1.4 (CruiseControl.NET-1.4-Setup.exe), downloaded from the CCNetLive website.

Run the setup executable file and, when prompted, you must specify your choices for a couple of actions:
‘Install CC.Net server as windows service’ must be checked so that the setup will install CruiseControl as a Windows service.
In the Services management console the CruiseControl service will be displayed with the name: CruiseControl.NET.
‘Create virtual directory in IIS for Web dashboard’ will create a virtual directory named ccnet in the machine’s IIS web server. If you have an IIS server installation supporting multiple web sites (this is not the case for Windows XP Professional) and prefer to have a separate web site for the CCNet web dashboard you should uncheck this option. This is my choice. In the next paragraph I will show you how to create an IIS web site for the CruiseControl.NET web dashboard.

When the install process is finished all the content will be installed in the folder:
C:\%ProgramFiles%\CruiseControl.NET (e.g. C:\Program Files\CruiseControl.NET).
Under this path you will find a directory called server, containing all the CCNet binary files and executables, and a directory called webdashboard, containing the CruiseControl.NET web interface.

→ top of post
→ top of paragraph

3.2. Create a CCNet Website in IIS

Here I will add and configure a Website in IIS for the CruiseControl.NET Webdashboard: the administrative interface of CruiseControl.NET.
Open IIS Manager in Administrative Tools, right-click on the Web Sites node and select New Web Site.
The Web site creation wizard will start.
Click Next and you will be prompted for a Web Site Description.
Type CCNet and click Next, leave Unassigned the IPAddress, choose a port number (say: 222) and leave empty the ‘Host Header for this site’ field, then click Next.
Choose C:\%ProgramFiles%\CruiseControl.NET\webdashboard as the path for the Website and click Next.
Allow ‘Read’ and ‘Run scripts’, the default, and click Next. The wizard is finished and the new Website created.

→ top of post
→ top of paragraph

3.3. Install Nunit

For the sake of our example we will need Nunit so, if you haven’t already done, install it on the same machine on which you have installed CruiseControl.NET.

You can find the latest Nunit release here at SourceForge.
This article is based on the release 2.4.6, currently the latest. You can install it by downloading: NUnit-2.4.6-net-2.0.msi.

After the installation you will have a new directory under %ProgramFiles% : C:\%ProgramFiles%\NUnit 2.4.6.

→ top of post
→ top of paragraph

4. CruiseControl.NET Server Configuration – General

All the configuration files we’re going to talk about are placed or are to be placed in:
C:\%ProgramFiles%\CruiseControl.NET\server.

CruiseControl.NET comes with two server executables: ccservice.exe which is the windows service installed by the installation setup and ccnet.exe which is a console application included for testing purposes.
It is much easier to debug a console application that a service so I strongly suggest to make your initial tests with ccnet.exe and carefully read the console output to get familiar with CCNet behavior.

Each of the two executables comes with a default configuration file (i.e.: ccservice.exe.config and ccnet.exe.config) that you don’t need to change at the moment.
Moreover both the server processes (windows service or console application) look for a file named ccnet.config in which you will place all the actual information needed by CCNet to learn what it is supposed to do and how it is supposed to do it.

ccnet.config is an xml file with a root element named <cruisecontrol> and a child element, named <project>, for each set of activities that we want CruiseControl.NET to execute, as shown in the following example:

<cruisecontrol>
<project name="project1">
    ...
  </project>
<project name="project2">
    ...
  </project>
</cruisecontrol>

In this tutorial we will setup our CruiseControl.NET configuration with two logical sets of activities.
For the sake of clarity we will benefit of the usage of xml entities.
We’ll define each ‘project’ configuration in a separate file and import all the files in ‘ccnet.config’ by means of entity definitions and entity declarations:

< !DOCTYPE cruisecontrol [
	< !ENTITY project1 SYSTEM "file:project1.xml.config">
	< !ENTITY project2 SYSTEM "file:project2.xml.config">
]>
<cruisecontrol>
  &project1;
  &project2;
</cruisecontrol>

Let’s focus, at first, only on the first project, so delete the second entity reference (i.e.: &project2; ) thus obtaining:

< !DOCTYPE cruisecontrol [
	< !ENTITY project1 SYSTEM "file:project1.xml.config">
	< !ENTITY project2 SYSTEM "file:project2.xml.config">
]>
<cruisecontrol>
  &project1;
</cruisecontrol>

→ top of post
→ top of paragraph

5. Structure of a ‘Project’ Configuration File

What we need to do now is creating a file named: project1.xml.config in C:\%ProgramFiles%\CruiseControl.NET\server
and use it to setup CruiseControl.NET main activities.
This file will contain what is called the ‘Project Configuration Block’ for the first CCNet activity that we want to configure.
First of all we need to assign a unique name to the root of the Project Configuration Block: the <project> tag. We then write:

<project name="1 - testProject">
  <webURL>http://192.168.15.2:222</weburl>
  <workingDirectory>C:\develop\CCnet\project1WorkingDir
  </workingDirectory>
  <artifactDirectory>C:\develop\CCnet\project1CCnetArtifacts
  </artifactDirectory>
  ...
</project>

Let’s talk about the first three children nodes:

represents the URL at which the current project is available through the web interface. We will see later why it is useful.
For now just make sure to set it to the IP of the server machine (in which you installed CCNet) and to the port that you chose for the WebDashboard website when you configured the web site in IIS (see: 3.2. Create a CCNet Website in IIS).

is the path to the main directory of this project and is meant to contain the checked out version of the project under integration.
This path will be accessible as an environment variable: %CCNetWorkingDirectory%, available to external scripts (we will see it later).
I use to place all the projects managed with CCNET in folders under a common directory named: C:\develop\CCnet.
For this test project I chose: C:\develop\CCnet\project1WorkingDir.

It is convenient to choose a directory in which to place all the stuff that will be used by CCNet (script files or executable files that you may want CruiseControl.NET to execute) as well as the workingDirectory in which CCNET will checkout the versioned files and the artifactDirectory in which it will output log files.
In the example above I chose the directory: C:\develop\CCnet as the container of all CCNet related stuff.

is the path to the directory where all the build logs for this project will be placed.

Apart from the three tags described above, the main blocks that we’re going to add to the project configuration file are:

• Source Control Block
• Trigger Block
• Labeller Block
• 9. Tasks Block
• 13. PreBuild Block
• 12. Publishers Block

→ top of post
→ top of paragraph

6. Source Control Block

Source Control configuration block tells CruiseControl.NET that the project named ‘1 – testProject’ is bound to a Subversion repository.
This means that the task performed when executing this project depends on the status of that particular Subversion repository.
As soon as CruiseControl.NET detects a new revision in the repository it updates its working copy and executes the tasks related to the current project.
Here is the xml excerpt:

<sourcecontrol type="svn">
<trunkUrl>svn://localhost/trunk</trunkUrl>
  <workingDirectory>C:\develop\CCnet\project1WorkingDir
  </workingDirectory>
  <username>ccnet </username>
<password> ccnet </password>
</sourcecontrol>

contains the url of the repository that we want to check for modifications (e.g., svn://svnserver/pathToRepo).
As we saw in the post Guide to Versioning a Visual Studio Solution with Subversion, TortoiseSVN and AnkhSVN, Subversion could host several repositories under a common folder, say: C:\develop\TestRepo.
But in that article, as well as in the current example, we set up only one repository and run svnserve with the command line: svnserve -d -r “C:\develop\test\repo”.
So, specifying the server name (localhost) and the path to the particular repository we’re interested in, turns out to be simply: svn://localhost/trunk (instead of: svn://localhost/SpecificRepositoryFolder/trunk);
is the directory that will contain the working copy checked out by CCNET;
sets the timeout for the source control operation. It defaults to 10 minutes and you can set it to a different amount of time in milliseconds (default) or specifying units (“millis”, “seconds”, “minutes”, “hours”); I left it out thus accepting the default.
If you want to set it to a different value remember to not choose a too short timeout value because if the timeout is exceeded the build will fail without providing information about the reason.
In that case the only way you can retrieve the actual reason of the build failing is by analyzing CCNET log file in the CruiseControl.NET\server folder (if you set log4net to the debug log level)
and must be set to a valid svn account that CCNET can use to access Subversion repository.

→ top of post
→ top of paragraph

7. Trigger Block

A trigger block is needed to specify when CruiseControl.NET will start a new integration cycle.
We want to check for the repository status continuously so we need an ‘Interval Trigger’ to tell CruiseControl.NET to perform integration periodically after a specified amount of time:

<triggers>
  <intervalTrigger name="Subversion" seconds="10" />
</triggers>

CruiseControl.NET, as far as project ‘1 – TestProject’ is concerned, polls the repository every 10 seconds to see if any changes has been committed.
The name attribute is used by CruiseControl.NET GUI to identify the trigger that requested the build;
The seconds attribute is the amount of time before triggering the next integration cycle.

Each time the time interval elapses, CCNET checks for modifications and, by default, runs integration only if changes are detected.

→ top of post
→ top of paragraph

8. Labeller Block

A label is created, at each integration cycle, to identify the specific build occurred.
Different labellers can be used to generate the label that CCNet will use to track the builds.

Other than the Labeller Blocks that come with the CruiseControl.NET distribution, many people provided plugin Labeller Blocks to target the generation of labels with specific formats.

A very good one, IMHO, is SvnRevisionLabeller by David Keaveny (much important to me because I recently contributed to the project).
This plugin allows labelling CruiseControl.NET builds with Subversion’s repository revision numbers and I think this is a really useful feature.
So this example will use SvnRevisionLabeller as the Labeller Block.
For detailed information about this plugin see my post: CruiseControl.NET and Subversion – SvnRevisionLabeller.

To use the SvnRevisionLabeller plugin in your installation of CruiseControl.NET you need to unzip the downloaded package and copy the assembly: ccnet.SvnRevisionLabeller.plugin.dll in the server folder directory under the CruiseControl.NET install path (e.g.: ‘C:\Program Files\CruiseControl.NET\server’).

Next you need to configure the Labeller Block in your project:

<labeller type="svnRevisionLabeller">
	<major>7</major>
	<minor>11</minor>
	<url>svn://localhost/trunk</url>
</labeller>

SvnRevisionLabeller will produce build labels in the format:

major.minor.svnRevision.build

where major and minor are the two values you set in the configuration block while svnRevision is the current version in the Subversion’s repository related to this project.
The build number is automatically incremented each time a new build is forced if no further modification has been committed to the repository.

<url> is the path to the repository used to retrieve the revision number (e.g. svn://svnserver/pathToRepo/trunk). Actually it should be filled with the same path used in the <trunkUrl> field of the Subversion Source Control Block.
In our example it is:

<url>svn://localhost/trunk</url>

Following is a configuration for SvnRevisionLabeller with the complete set of fields:

<labeller type="svnRevisionLabeller">
<prefix>Test-</prefix>
  <major>7</major>
  <minor>11</minor>
  <url>svn://localhost/trunk</url>
  <username>ccnet</username>
<password>ccnet</password>
</labeller>

Such a configuration will produce a label with the following format: Test-major.minor.svnRevision.build.
<username> and <password> are the username and password of a valid Subversion account for the repository specified in the <url> field.

You can use in an external script the build label produced, which is stored in an environment variable.
It can be useful to flag release version of output dlls.
You can access the build number from a script with the syntax: %CCNetLabel% or from a C# application with the following row:

Environment.GetEnvironmentVariable("ccnetlabel");

If you used the SolutionInfo approach in your Visual Studio solution (see my post: SolutionInfo and Partitioned Single Solution) you can use the build label produced by SvnRevisionLabeller to update the AssemblyFileVersion attribute in the SolutionInfo.cs file.
In this way you can provide consistent versioning of the released assemblies together with easy trackability of the corresponding source code’s revision.

Be careful not to use the <prefix> tag in this case because you need to set AssemblyFileVersion to a string in the format:
major.minor.svnRevision.build
with all of the 4 fields being numerical values.

→ top of post
→ top of paragraph

CruiseControl.Net Tutorial – Part 2 >>

Why do we need a continuous source code integration and build system? well, this helps the QA team by allowing then to not spend more time in syncing the source and doing a build everytime or even working on a relatively older build. This works as a perfect backup for your Source Control and also your deployment server build. This also allows to align the builds numbers to be same as your assembly\file version and also to the source control label there by making a particular build to be a complete unit in itself in terms of readiness for deployment or using the same for development.

Now coming back to build server where we can use cruise control .NET for source integration along with a couple of batch scripts to control the build number and assembly version. CCNET pings the source control (VSS or Vault etc) after every 30 mins (this is a default value and can be changed) to see if there are any modifications. If there are then it triggers a build and publishes it on the Build Server. Once done sleeps again for 30 mins unless it is Forced for a build in between i.e. you can manually force a build in between sleeps.

Let me explain the two components of build server in details below:

1) Cruise Control .NET:
Its an open source build and integration engine which can be downloaded freely from http://confluence.public.thoughtworks.org/display/CCNET/DownloadOnce installation is done CCNET (CruiseControl.NET) needs to be configured according to your requirements. the config file can be found at “%SYSTEMDRIVE%\Program Files\CruiseControl.NET\Server\ccnet.config”.
A Sample configuration looks like below (using Sample Project and Source Gear Vault as source control provider):

2) Batch Scripts (Same Build and Assembly Version):
There are two batch scripts used to control the assembly version. For any executable or dll assembly version is generated based on AssemblyVersion attribute defined in AsseblyInfo.cs file. In order to have same Label and assembly version we can use batch script to change the attribute at runtime and then revert the same at the end of build process again during runtime.

Once the source integration is done by CCNET and is ready for build we change the file attributes of AssemblyInfo files (more in case of multi project solution) to -R so that AssemblyVersion attribute can be changed to build label thereby making the version of generated dll’s and exe’s with the same version. Now to revert back we use another script which changes the AssemblyVersion attribute back to 1.0.0.0 and change the file attribute back to +R there by dodging the source control to not treat this as a modification otherwise it will consider this as a modification and trigger the build again and go to an infinite loop of build

For mutli project systems where you need many assemblyinfo files to be changed you can use some utilities like replace.exe http://www.bestcode.com/assets/downloads/replace/replace.exe
Below is an example of how a batch script would look like:
#Test1.bat
attrib /S -R AssemblyInfo.cs replace.exe -find “1.0.0.0″ -replace “%CCNetLabel%” -fname AssemblyInfo.cs

Complete reference on the configuration blocks can be found at http://ccnet.sourceforge.net/CCNET/ One of the useful publisher which is missing in the above config is Email publisher where-in you can send mails for build success\failure to single\set of people. This help in tracking the build failures and also QA team notification in case of build succeeds.

This can very well be integrated with NUnit for executing test cases ones the build succeeds. This post doesnt cover this though more information on this can be found at CCNET link provided above.

There is a UI support too for CCNET to control the build trigger and view build results\logs. it can be found at http://[BuildServer]/ccnet . The web dashboard for ccnet looks like:

Hope this post will help in case you are planning to set up an automated build and integration system or you are looking for a solution to have same build and assembly version for you current systems builds.

bye for now.

TFS 2008 introduced Team Build which enables continuous integration.  But if you come from a traditional SVN/CruiseControl background, you will be please to know that there is also a CC.NET plugin available.

And with preview release of the powershell provider for IIS 7, it is possible to easily creating the websites, setting permissions etc without the scripting pain of the past.