Cruce Control.Net(CC.NET) for Visual Studio 2008/2010 or SVN

Introduction to CC.NET:

CruiseControl.NET (CCNet) consists of a suite of applications, but at its core is the CruiseControl.NET Server which is an automated integration server.
The Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.
Effectively, integration becomes as easy as checking in code. Using an automated integration server not only makes integration easy, it also guarantees that an integration build will happen. There is no danger of developers forgetting to validate their changes after checking in.
The CCNet Server offers several key features:

• Integration with a variety of Source Control systems
• Integration with other external tools, such as NAnt and Visual Studio
• Can build multiple projects on one server

Installation Prerequisites:

To get CruiseControl.NET server up and running, you need to have the following environments set up and installed:

• Microsoft.NET Framework Version 2.

Installation Instruction:

1. CC.NET 1.4.2 can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=71179&package_id=83198
2. By default CC.NET gets installed in {Program Files}\ CruiseControl.NET which in turn contains 3 subfolders i.e. Examples, server and webdashboard.

1) Copy the ccnet.vsts.plugin.dll assembly into the server directory for CCNET. 

2) Configure ccnet.config to referece VSTS for source control.  You will need something like this:-     However, for full details on configuring the plug-in see

                  <sourcecontrol type="vsts">

                    <server>my_team_foundation_server</server>

                    <project>$/Foobar</project>

                    <workingDirectory>c:\projects\Foobar</workingDirectory>

                  </sourcecontrol>

http://confluence.public.thoughtworks.org/display/CCNET/Visual+Studio+Team+Foundation+Server+Plugin

3) Restart ccnet and enjoy.

NOTE:

To get the source to compile / run you need the following assemblies installed on the machine (If you have Team Explorer

installed on that machine then they will already be present).

Microsoft.TeamFoundation.Client.dll

Microsoft.TeamFoundation.Common.dll

Microsoft.TeamFoundation.Common.Library.dll

Microsoft.TeamFoundation.dll

Microsoft.TeamFoundation.VersionControl.Client.dll

Microsoft.TeamFoundation.VersionControl.Common.dll

Microsoft.TeamFoundation.VersionControl.Common.Integration.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.Provision.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.QueryLanguage.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll

Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll

These will be in your GAC if you have the Visual Studio 2005 Team Explorer client installed on your machine

 - otherwise you'll need to copy them from one that does.  If you don't want to install the

Team Foundation Client on your build machine then you must copy the assemblies above into

the CCNET server directory along with the ccnet.vsts.plugin.dll

Good luck.

Configuration settings:

Instead of writing build scripts to support Continuous Integration, main configuration task in getting an instance of CruiseControl.NET running for your project is editing the Server's configuration file. This is defined in an XML file which by default is called ccnet.config in the same directory as the server application. By default, the server watches this file for updates and reloads it if the file changes.

ccnet.config example:

<cruisecontrol>

<project name="RiskModel4">

   

   

    <sourcecontrol type="svn">

<server>my_team_foundation_server</server>

<project>$/Foobar</project>

      <workingDirectory>{RM working Dir}</workingDirectory>

      <executable>{Program Files}\VisualSVN\bin\svn.exe</executable>

      <username>username</username>

      <password>password</password>

    </sourcecontrol>

   

    <triggers>

      <intervalTrigger name="Subversion" buildCondition="IfModificationExists" />

    </triggers>

    <tasks>

     

      <msbuild>

        <executable>{WINDOWS}\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe

        </executable>

        <workingDirectory>{AppTier working Dir}</workingDirectory>

        <projectFile>{ AppTier working Dir}\.sln</projectFile>

        <buildArgs>/noconsolelogger /v:quiet /p:Configuration=Debug</buildArgs>

        <targets>Build</targets>

        <logger>{CC.NET Path}\server\ThoughtWorks.CruiseControl.MSBuild.dll</logger>

      </msbuild>

     

       <exec>

        <executable>{ AppTier working Dir}\RunTests.bat</executable>

        <baseDirectory>{ AppTier working Dir}</baseDirectory>

       </exec>

     </tasks>

   <publishers>

      <merge>

        <files>

          <file>C:\testResults.trx</file>

        </files>

      </merge>

 <email from="buildmaster@mycompany.com" mailhost="smtp.mycompany.com" mailport="25>

<includeDetails>True</includeDetails>

    <users>

        <user name="BuildGuru" group="buildmaster" address="buildguru@mycompany.com"/>

        <user name="Developer" group="developers" address="edeveloper@thoughtworks.com"/>

    </users>

    <groups>

        <group name="developers" notification="Failed"/>

        <group name="buildmaster" notification="always"/>

    </groups>

    </publishers>

  </project>

</cruisecontrol>

1 The root tag in the Server Configuration file is the <cruisecontrol> tag

2. A <project> block defines the entire configuration for one project running in a CruiseControl.NET server.

3. name attribute defines the name of the project - this must be unique for any given CruiseControl.NET server

4 <workingDirectory> defines the Working Directory for the project (this is used by other blocks). Relative paths are relative to a directory called the project Name in the directory where the CruiseControl.NET server was launched from. The Working Directory is meant to contain the checked out version of the project under integration. This folder is unique per project to prevent problems with the build.

5 <artifactDirectory> defines the Artifact Directory for the project (this is used by other blocks). Relative paths are relative to a directory called the project Name in the directory where the CruiseControl.NET server was launched from. The Artifact Directory is meant to be a persistence location for anything you want saved from the results of the build, e.g. build logs, distributable, etc. Make sure this folder us unique per project to prevent problems with reporting about a build.

6. type attribute specifies the type of Source Control E.g. - SVN

<trunkUrl> specifies the location of the SVN home directory. The pathname can be either absolute or relative to the project artifact directory.

<executable> specifies the path to the svn.exe.

<login> specifies the user login for source control

< password> specifies the password for source control

7 <triggers> Trigger blocks allow you to specify when CruiseControl.NET will start a new integration cycle.Typically; you'll want to use an Interval Trigger. Also useful is the Schedule Trigger for implementing daily builds.Use the Filter Trigger to prevent builds from occurring at certain times (such as when your source control repository is undergoing backup).
If you want to set up a project that will only respond to force build requests, you should specify an empty trigger section like this: <triggers/>.

buildCondition attribute specifies the trigger condition. E.g. IfModificationExists

Types of Integration Trigger Block are:

• Filter Trigger
• Interval Trigger
• Multiple Trigger
• Project Trigger
• Schedule Trigger
• Url Trigger

NOTE: Like all triggers, the filterTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block

Filter Trigger:

The Filter Trigger allows you to prevent builds from occurring at certain times or on certain days (such as when your source control repository is undergoing backup). It is used to decorate an existing trigger. For example, if you have set up a Interval Trigger to cause a new build every 5 minutes, you can use the Filter Trigger to create a window during which the build will not run.

Example:

<filterTrigger startTime="23:30" endTime="23:45">

    <trigger type="intervalTrigger" seconds="60" />

    <weekDays>

        <weekDay>Sunday</weekDay>

    </weekDays>

</filterTrigger>

This trigger suppresses builds if any modifications are made between 23:30 and 23:45 on Sunday nights.

Interval Trigger:

The Interval Trigger is used to specify that an integration should be run periodically, after a certain amount of time. By default, an integration will only be triggered if modifications have been detected since the last integration. The trigger can also be configured to force a build even if no changes have occurred to source control.

Example:

<intervalTrigger name="continuous" seconds="30" buildCondition="ForceBuild"/>

 Multiple Trigger:

The Multiple Trigger is used to support the execution of multiple nested triggers. Each trigger will be executed sequentially in the order specified in the configuration file. By default, if any of the triggers specify that a build should occur then a build will be triggered. The build condition will be ForceBuild if any trigger returns a ForceBuild condition. Otherwise, the build condition will be IfModificationsExist if any trigger returns that condition. Multiple Triggers can contain nested multiple triggers.

Example:

<multiTrigger operator="And">

        <triggers>

            <intervalTrigger />

            <filteredTrigger startTime="23:30" endTime="23:45" />

        </triggers>

    </multiTrigger>

Project Trigger:

The Project Trigger is used to trigger a build when the specified dependent project has completed its build. This trigger can help you split your build process across projects and servers. For example, you could have a CCNet project that will trigger the regression test suite once the main development build has completed successfully. This dependent build could be running on either a local or a remote CCNet server.

Example:

<projectTrigger serverUri="tcp://server:21234/CruiseManager.rem" project="Server">

    <triggerStatus>Success</triggerStatus>

    <innerTrigger type="intervalTrigger" seconds="30" buildCondition="ForceBuild"/>

</projectTrigger>

Schedule Trigger:

The Schedule Trigger is used to specify that an integration should be run at a certain time on certain days. By default, an integration will only be triggered if modifications have been detected since the last integration. The trigger can be configured to force a build even if have occurred to source control.

Example:

<scheduleTrigger time="23:30" buildCondition="ForceBuild" name="Scheduled">

    <weekDays>

        <weekDay>Monday</weekDay>

    </weekDays>

</scheduleTrigger>

Url Trigger:

The Url Trigger is used to trigger a CCNet build when the page at a particular url changes. The Url Trigger will poll the specified url according to a configured polling interval to detect if the last modified date of the page has changed since the last integration.

This trigger is especially useful in reducing the load on your source control system caused by the polling for modifications performed by an Interval Trigger. If your source control system supports trigger scripts (such as the use of commitinfo scripts in CVS), you can use create a trigger to touch the page that is being monitored by CCNet to start a new integration.

Example:

<urlTrigger url="http://server/page.html" seconds="30" buildCondition="ForceBuild"/>

8. <tasks> Tasks Blocks are the action elements of CruiseControl.Net. They're the elements that do things, like executing a program, running tests, or send email results.

<msbuild> block used to execute MsBuild projects, which are the default project format for Visual Studio 2005 projects and can also be compiled by using the MSBuild application that ships with the .NET 2 Framework.

<executable> The location of the MSBuild.exe
< workingDirectory > The directory to run MSBuild in - this is generally the directory containing your build project. If relative, is a subdirectory of the Project Working Directory

<projectFile> defines the name of the build project to run, relative to the workingDirectory.

< buildArgs> defines Any extra arguments to pass through to MSBuild

< targets > A semicolon-separated list of the targets to run

<logger> The full path to the assembly containing the custom logger to use. Arguments can be passed to the logger by appending them after the logger name separated by a semicolon.

9 <exec> block defines related to Unit test files

 <executable> defines bat file path E.g.{Project working Dir}\RunTests.bat

<baseDirectory> block defines path of working Dir.

The RunTests.bat contains following commands

del C:\results.xml

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe" /testcontainer:D:\BackUP\RMSubVertion\RiskModel4\Test\bin\x86\Debug\Test.dll /resultsfile:C:\results.xml

This basically deletes the results.xml which is created by the MSTest.exe each time it runs to avoid appending the file.

Then run the MSTest.exe with the Test.dll as input.

10 First we need to merge the results.xml file to the build log. To do that, update the publishers section of the ccnet.config file as given below

<publishers> 

    <merge>

    <files>

        <file>{WorkingDirectory}\results.xml</file>

    </files> 

    </merge>

    ... 

</publishers> 

Then modify the ccservice.exe.config (or ccnet.exe.config if you use ccnet.exe instead of the ccservice) file by modifying the xslFiles section as given below:

<xslFiles>

    <file name="xsl\header.xsl"/>

    <file name="xsl\compile.xsl"/>

    <file name="xsl\mstestsummary.xsl"/>

    <file name="xsl\modifications.xsl"/>

</xslFiles>

In the above section, removed the unittests.xsl which is there by default and added mstestsummary.xsl instead.
Now we need to configure the Web dashboard. Open the dashboard.config file and update the buildPlugins section as given below:

   <buildPlugins>

      <buildReportBuildPlugin>

        <xslFileNames>

          <xslFile>xsl\header.xsl</xslFile>

          <xslFile>xsl\modifications.xsl</xslFile>

          <xslFile>xsl\compile.xsl</xslFile>

          <xslFile>xsl\MsTestSummary.xsl</xslFile>

          <xslFile>xsl\fxcop-summary.xsl</xslFile>

          <xslFile>xsl\NCoverSummary.xsl</xslFile>

          <xslFile>xsl\SimianSummary.xsl</xslFile>

          <xslFile>xsl\fitnesse.xsl</xslFile>

        </xslFileNames>

      </buildReportBuildPlugin>

      <buildLogBuildPlugin />

      <xslReportBuildPlugin description="MSTest Report" actionName="MSTESTReport" 

            xslFileName="xsl\MsTestReport.xsl"/>  

Again, removed the unittestsummary.xsl and added mstestsummary instead. The new xslReportBuildPlugin element causes a link to be displayed on the left side called “MSTest Report”, and when clicked it will display the detailed test results in a table.

11. The email publisher can be used to send email to any number of users. It is common to include one user who gets an email for every build and then also send email to every developer who checked code in for this build.

Note: Make sure that all of the [Merge Publisher]s, along with the Xml Log Publisher task are done before the <email> publisher, or else you won't be able to include output from the build in the email.
A common mistake is to put the email task in the <tasks> section instead of the <publishers> section.
If an error occurs in the <tasks> section, the remaining tasks in that section are skipped, and CC.Net goes right to the <publishers> section.So if you put the <email> tasks in the <tasks> section, you'll never get any failure messages.

<email from="buildmaster@mycompany.com" mailhost="smtp.mycompany.com" mailport="25" includeDetails="TRUE">

    <users>

        <user name="BuildGuru" group="buildmaster" address="buildguru@mycompany.com"/>

        <user name="JoeDeveloper" group="developers" address="joedeveloper@thoughtworks.com"/>

    </users>

    <groups>

        <group name="developers" notification="Failed"/>

        <group name="buildmaster" notification="always"/>

    </groups>

Using CC.Net

Server folder contains two executables i.e. ccnet.exe and ccservice.exe.

ccnet.exe

The ccnet.exe is a console application which can be used to debug the CC.Net before running as service.

ccservice.exe

Once console application is working fine, ccservice.exe. which is windows service can be run for continuous integration.