How to Hook Up a VS.NET 2005 Solution With CruiseControl.NET in a Few Minutes

原文地址：http://weblogs.asp.net/jdanforth/pages/How-to-Hook-Up-a-VS.NET-2005-Solution-With-CruiseControl.NET-in-a-Few-Minutes.aspx

我在部署我的CI服务器的时候，这篇文章对我帮助很大，特地转来我的博客，共享之。以下为原文

This is a short "primer" on how to get your CruiseControl.NET (CC.NET) Continuous Integration (CI) Server up and running with a very small configuration, and it will only take you about 5 minutes or so. I’m pretty new to CC.NET so I thought I would share some of the stuff I learned about it when setting it up. I've used it before, but that was some time ago and now I’m planning on using it for an upcoming project so I had to brush things off and see what had changed lately.

I’m listing some NAnt resources as well here, even though I’m not covering NAnt now (but probably will in a future update). If you want to read about NAnt and CC.NET, Joe Field got a great article on it, and I'm sure there are other CC articles out there.

Updates

Nov 25, 2006 - Added information about how to use msbuild.exe and a small sample configuration. 

Why CruiseControl.NET?

So why would you like to use something like CruiseControl.NET? Say you have an ASP.NET Web application solution with a few class library projects and some NUnit tests, you keep track of it using VSS and you want to make the move to CI. Say you want it to check out, compile, test and report every time new code is checked in or by schedule every night (this is up to you and dead simple to change). If this is something you’d like to do, keep reading.

Note that this has nothing to do with the Unit Testing features of (some of the) VS.NET Team System Editions, but CC.NET is so flexible it’s possible to use that feature too, via the <msbuild> <task> for example, but that’s for another time. I've updated this page (at the end) with a sample configuration for compiling using msbuild, but not for running unit tests with it (yet) 

If you know the basics and just want to get to the configuration file, jump to the section near the end called “CC.NET Configuration” where you got the XML I came up with. Good luck.

Tools and Products

I'm using these tools and products:

- Visual Studio.NET 2005 + Visual Source Safe

- CruiseControl.NET version 1.1.2527, tool for doing Continuous Integration

- NUnit version 2.3.6293 for .NET 2.0, tool and framework for unit testing your code

- NAnt + NAntContrib version 0.85, tool and framework for performing complex build tasks, similar to msbuild.exe. The Contrib

package contains extra stuff you want to use as a NAnt user (not used in this paper yet, but make sure it’s the same versions if you decide to install them now)

Resources

Some good reasources, where you can download the things I listed above:

- CruiseControl.NET– http://ccnet.thoughtworks.com/

- NUnit – http://www.nunit.org/

- NAnt – http://nant.sourceforge.net/ (not used in this paper yet)

- NAntContrib – http://nantcontrib.sourceforge.net/ (not used in this paper yet)

- Great (longer) tutorial on CC.NET by Joe Field -http://joefield.mysite4now.com/blogs/blog/articles/146.aspx

Ways of Building Your Code

Just a few words about different ways to build/compile your code. There are various ways to do this of course, but a few typical ones:

- Let CC.NET build it by using the devenv.exe program (this requires you to install VS.NET on the build server)

- Let CC.NET hand over the build process to msbuild.exe.

- Let CC.NET hand over the build process to NAnt, which in itself can use devenv.exe or msbuild.exe to build you code.

Using devenv.exe is a simple way of doing it, CC.NET got a <task> for it, you just point at your solution file, and I’m sure it will be enough for most people who just wants to get going. But, it won’t give you the precise control you might want to have.

This paper will cover the first one, using devenv.exe, and the second one using msbuild.exe, but it should be enough to get you started.

Download

This tutorial assumes that you already have VS.NET 2005 installed. So start off by downloading the other products listed above. There’s no need to install NAnt unless you want to use that as your build tool. The simplest configuration of CC.NET handles the build on its own, without even involving msbuild.exe, but I recommend that you look at, learn and consider using NAnt for more complex/complete build tasks. You find the links in the Resource section.

Installing

Installing these things is pretty straight forward and needs no help. A few words though... Most of these products are actually mimicking the beautiful way most Java tools are installed – unzip into a directory of your choice. But I recommend using the .msi installers, especially that of CC.NET as it installs a Windows Service as well and a few useful shortcuts to the CC.NET configuration file and the documentation.

The CC.NET .msi installer also creates a website (CC.NET Dashboard) on your IIS if you got that installed. For some reason it doesn’t create any shortcuts to it from the Start menu. I’ll talk about that later.

Speaking about documentation I have to say that the docs are great in most places. Thing is that the stuff you need to read are spread out in several places and I couldn’t find any decent CC.NET configuration that suited me. That’s why I’m writing this paper...

My Test Solution

So, we need something to test on, so I created this mini web app, which consists of 3 VS.NET projects:

- A web app (I used the Web Application Project template for this)

- A class library for a simple Database Access Layer project

- A class library for a few unit tests (using NUnit)

Make sure you install these things so that the solution file is sitting in a folder “above” these projects, like this:

Solution (JohansTestSystem)

          Web Project - Johan.Web

          DAL Project - Johan.DAL

          Test Project - Johan.Test

This will make everything sort of easier for all tools to handle the code and the projects. Start by creating an empty Solution and add new Projects to it as you go. VS.NET will make sure everything gets created where it should. It doesn’t matter where on your disk you are creating these projects, because we will check them out to and build them in another directory.

Finally – add them to Visual Source Safe (or whatever source control system you are using). CC.NET got support for many source control systems.

CC.NET Configuration

Now, to the reason why you are reading this – let me show you an example of a pretty slim configuration to start with. You find the configuration file (ccnet.config) in the /server/ directory of where you installed CC.NET, or via the Start menu created by the CC.NET installation. My examples does not involve NAnt at all right now and will let CC.NET handle the build by calling the devenv.exe or msbuild.exe.

Devenv.exe Configuration Sample 

To understand why this first configuration file looks it does, I'll give you some info about where I have installed things and such:

- VSS is installed in C:\Program Files\Microsoft Visual SourceSafe\

- My VSS database is installed in C:\VSS\

- I got a user called “Johan” in VSS

- The solution file is checked into the VSS-project $/JohansTestSystem.root

- I’m checking out and building the solution in the C:\CI\ directory, which means the solution will be checked out to C:\CI\JohansTestSystem\

- I want CC.NET to look for newly checked in files every 60 seconds

- I want CC.NET to use VS.NET devenv.exe to build my solution

- I got NUnit installed in C:\NUNIT\

- I want NUnit to test the application after the build

This is a small, if not the minimum, example of a configuration file for this job:

 <cruisecontrol>

  <project name="Johans Test System">

    <sourcecontrol type="vss" autoGetSource="true"applyLabel="true">

      <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>

      <project>$/JohansTestSystem.root</project>

      <username>Johan</username>

      <password></password>

      <ssdir>c:\vss\</ssdir>

      <workingDirectory>C:\CI\</workingDirectory>

      <cleanCopy>true</cleanCopy>

    </sourcecontrol>

   

    <triggers>

      <intervalTrigger seconds="60" />

    </triggers>

    <tasks>

      <devenv>

        <solutionfile>c:\CI\JohansTestSystem\JohansTestSystem.sln</solutionfile>

        <configuration>Debug</configuration>

        <buildtype>Build</buildtype>

        <executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com</executable>

        <buildTimeoutSeconds>60</buildTimeoutSeconds>

      </devenv>

      <nunit path="C:\nunit\bin\nunit-console.exe">

        <assemblies>

          <assembly>C:\CI\JohansTestSystem\Johan.Test\bin\Debug\Johan.Test.dll</assembly>

        </assemblies>

      </nunit>

    </tasks>

   

    <publishers>

      <xmllogger />

    </publishers>

 

  </project>

</cruisecontrol>

You may want to consider not labeling the code after a build (applyLabel="false") and use another trigger instead of the <intervalTrigger>.

Msbuild.exe Sample Configuration

Now I'll show you how to change the configuration above to use msbuild.exe instead. One good reason do use this configuration is that VS.NET does not have to be installed on the build server. NOTE! If you're using the new Web Application Project template for a website project, you must copy the file Microsoft.WebApplication.targets to C:\Program Files\msbuild\microsoft\visualstudio\v8.0\webapplications\ directory, or the build will fail! The reasons for this is described in several places on the Net.

The circumstanses described earlier are still valid, except that we're using msbuild.exe instead of devenv.exe. So, change the ccnet.config file to look like this:

<cruisecontrol>

  <project name="Johans Test System">

    <sourcecontrol type="vss" autoGetSource="true"applyLabel="true">

      <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>

      <project>$/JohansTestSystem.root</project>

      <username>Johan</username>

      <password></password>

      <ssdir>c:\vss\</ssdir>

      <workingDirectory>C:\CI\</workingDirectory>

      <cleanCopy>true</cleanCopy>

    </sourcecontrol>

   

    <triggers>

      <intervalTrigger seconds="60" />

    </triggers>

   

    <tasks>

      <msbuild>

        <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>

        <workingDirectory>c:\CI\JohansTestSystem</workingDirectory>

        <projectFile>JohansTestSystem.sln</projectFile>

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

        <targets>Build</targets>

        <timeout>15</timeout>

        <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>

      </msbuild>

      <nunit path="C:\nunit\bin\nunit-console.exe">

        <assemblies>

          <assembly>C:\CI\JohansTestSystem\Johan.Test\bin\Debug\Johan.Test.dll</assembly>

        </assemblies>

      </nunit>

    </tasks>

   

    <publishers>

      <xmllogger />

    </publishers>

 

  </project>

</cruisecontrol>

The changes are in bold. The <msbuild> task and the values should be pretty straight forward and they are well described in the ccnet documentation for msbuild. Msbuild doesn't come with XML output so a few friendly people made an XML logger for it, which you need todownload and put in project working directory (for me it's C:/CI/JohansTestSystem/) and also reference in the <msbuild> task section (as you can see above). Read about msbuild and the logger on this page.

Finally, you need to do a few touches to the Dashboard configuration, which is the file called dashboard.config in c:/<ccnet>/webdashboard/ directory. First, add the compile-msbuild.xsl to the <xslFileNames> section, so that you get a somewhat nicer looking style to the msbuild output:

<xslFileNames>

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

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

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

       <xslFile>xsl\unittests.xsl</xslFile>

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

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

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

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

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

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

</xslFileNames>

You could remove the other files that you're not using, or just leave them there, it doesn't hurt. Then you would like to add the msbuild output to the dashboard menu. In the same configuration file, add a <xslReportBuildPlugin> section:

<xslReportBuildPlugin description="MSBuild Output"actionName="MSBuildOutputBuildPlugin"xslFileName="xsl\msbuild.xsl" />

Run

Now, start CC.NET by clicking on the CruiseControl.NET shortcut on the desktop or find it via the Start menu, or look for ccnet.exe in the /server/ directory where you installed CC.NET.

Even better might actually to be to open up a command prompt and run it from there, because you may get at few errors or warnings the first time and it’s easer to CTRL-C and look at them from there. Don’t bother starting the CC.NET Windows Service until you got a decent config that works well.

If all is well, CC.NET should do its job and go back to sleep mode again, waiting for the next time to trigger. You should have gotten loads of output in the console window and something like this in the end:

[Johans Test System:INFO] Integration complete: Success - 2006-11-11 18:45:23

If not, go back and look at your config file where some path might be wrong. The errors output from CC.NET isn’t the best...

The CC.NET Web Dashboard

If you want to look at the results from the last build, or force a new build, you can use the CC.NET Dashboard. Note that ccnet.exe must be running.

Open a browser and go to http://<your CI host>/ccnet/ and you should see the dashboard where the right hand side shows the projects described in your configuration file, in this case only one project. Click on your project name and then on the report for the latest build which will show you the files modified since last time (and by whom), and how the test run went.

On the left hand side you can click on a number of links to get detailed reports if you like. The NUnit Details report is a good one, and as you can see, CC.NET got support for a number of other tools; NAnt, FxCop, NCover and so on.

That’s it for now. This page will probably get updated with other sample configs where I use NAnt and other configurations with msbuild. As soon as I get a few minutes to write something...