CruiseControl.NET配置
前些日子，总结了一个NAnt的学习总结。后来就放下了，松散了一阵子。CruiseControl.NET(以下称CC.NET)，是我在学习完NAnt以后才开始看的，当时学起来就是在网上疯狂的找资料。现在就做一个关于CC.NET的总结吧。
CC.NET是一个开源软件，用它来做日构建实在是在好不过了。而且很方便，只需要配置一个配置文件就可以了。
CruiseControl.NET-1.4.1-Setup.exe（服务器端）
CruiseControl.NET-CCTray-1.4.1-Setup.exe（客户端）
首先，确保你的电脑上已经安装了IIS（因为CC.NET会在IIS里面建立一个虚拟目录作为Web服务）。
其次，是安装.Net framework 2.0(后面会用到，例如MSBuild)
OK，现在可以安装CruiseControl.NET-1.4.1-Setup.exe（服务器端）了，基本上一路回车就好了。
然后，接着安装CruiseControl.NET-CCTray-1.4.1-Setup.exe（客户端）同上。
安装成功，不要高兴太早。你打开IIS看看你的默认的web站点下面有名为ccnet的虚拟目录吗？
如果有，右键浏览，如图所示：
下面我们来看看解决方法：
控制面板->Component Services,展开树形结构：Computers->my computer->COM+ Applications,有问题的话，会弹出出错信息。
msdtc –install
可能是安装顺序有问题，强烈建议按照建议的顺序安装
2.检查IIS下虚拟目录ccnet的default页面，如果有冗余，只保留一个，其他的删除。
3.可能是COM+组件的权限问题。展开上面提到的COM+组件属性结构，查看IIS OUT-of-process pooled Applications 的属性，查看他的identity标签页，勾选为 Ssystem Account
IIS的默认权限应设勾选集成WINDOWS验证模式
如果页面出现：failed to access the iis metabase
在此基础上我先配置，然后卸载过之前安装的版本，在重新安装，OK，问题解决。
是什么也没有的。这时，我们可以通过File=》Setting=》Build Projects,弹出窗体：
默认是选择“Connection directly using .NET remoting”,点击OK，显示窗体：
这时，我们注意到，在左边的Build Server里面显示了我们的服务器，在右面的Available Projects确实空白。别着急，因为，我们还没有建立Project。
我们所有的对CC.NET进行的控制，都是通过修改一个配置文件（位于安装目录下的Server里面：C:\Program Files\CruiseControl.NET\server\ccnet.config）进行的。
<cruisecontrol>
<project >
</project>
</cruisecontrol>
只是，我们通过CCTray进行添加，就会出现
点击OK，这是CCTray显示如图：
这时，我们可以去强制编译，点击“Force Build”，这时，CCTray会有变化，但是，我们的操作是没有意义的。因为，我们还什么都没有做。
到现在为止，我们就添加了一个Project，以下我们的操作都是在这个Project基础上进行的。
配置文件中的内容：
<cruisecontrol>
<project >
<webURL>http://127.0.0.1/ccnet</webURL>
<artifactDirectory>F:\Test\CITest\Code\Log</artifactDirectory>
<workingDirectory>F:\Test\CITest\Code</workingDirectory>
<sourcecontrol type="vss" autoGetSource="true">
<ssdir>D:\SourceSafe6.0d\TEST1\</ssdir>
<executable>D:\SourceSafe6.0d\VSS\win32\SS.EXE</executable>
<project>$/</project>
<username>cf</username>
<password>****</password>
</sourcecontrol>
</project>
</cruisecontrol>
说明：
webURL:通过web方式访问ccnet项目的地址<webURL>，ccnet提供的dashboard，下文中的dashboard就指用浏览器访问ccnet），远程就把localhost换成装了ccnet的主机地址，目前可以用http://10.0.3.146/ccnet访问这两个测试项目
workingDirectory：是下载的源码将会被保存的目录，如果没有设置，则会自动被保存在安装目录下server子目录下以project name为名称的目录下。当Project和sourcecontrol都含有workingDirectory时，以Project下面的为主。
artifactDirectory：对这个项目的监控过程的日志记录目录。（具体不知是做什么）
autoGetSource：为True时，CC.Net会通过监视VSS中代码的版本变化，自动从版本管理器中获取源代码
个人认为：服务器所在的路径，srcsafe.ini所在的文件夹，此例为本机，一般都是形式，为网络路径
网络：在ccnet服务器上的一个路径，可以是相对于该ccnet项目的主目录的路径，在需要执行持续集成的时候，用于存放ccnet从版本库中取出的版本，进行编译并执行持续集成
配置完成后，我们要重新启动服务。方法：打开”运行”，输入“Services.msc”，回车即可。
启动这个服务“CruiseControl.NET Server”。
有时候在启动这个服务的时候会出现一些奇怪的问题，我现在就我遇到的问题给大家总结一下。
我们可以通过右键点击这个服务，然后选择属性弹出窗体如下：
看Log On这个Tab，有两种登陆方式，一个是Local System account和This account。当我没有联机的情况下，我选择默认的方式就可以，也就是Local System account。但是当我在公司，以域的方式登陆的情况下，就必须选择This account，然后，选择我的域账号，登陆才可以。具体原因不清楚，大家遇到问题可以试一下。（了解的人，希望帮忙解释一下）。
当CC.NET中的一些语法错误时，同样会产生错误。
如图：
这时，我们就需要通过事件查看器来看看发生了什么错误。
打开控制面板=>管理工具=>事件查看器。然后选择左面事件查看器下面的Application，在右面的详细列表里面，可以看的一个“Error”，双击，可以查看错误描述。
如图：
从上图，很容易的就看出，我们的配置文件的第2行有问题（我特意将Project写成了Project1）。一般的问题都可以从这里看到并解决。
如果启动服务没有问题，我们打开CCTray，点击强制Build，过一会就会出现下图所示，说明已经编译成功。
同样，我们获取了代码，接下来的任务就是编译解决方案。在CC.NET里面，我们还是通过MSBuild来编译我们的解决方案的。脚本如下：
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>F:\Test\CITest\Code\TestProject</workingDirectory>
<projectFile>test.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build;Test</targets>
<timeout>900</timeout>
<logger>F:\Test\CITest\ThoughtWorks.CruiseControl.MSBuild.dll</logger>
</msbuild>
</tasks>
说明：
executable:msbuild所在的路径，一般为系统目录下的Microsoft.NET\Framework\v2.0.50727此例是.net framework 2.0，可能有更高的版本，是你的实际情况而定。
workingDirectory：我们要编译的解决方案所在的路径
projectFile:我们要编译的解决方案名
logger: 记录编译的详细日志，需要单独下载这个程序集，放在工作目录(workingDirectory)下，下载路径 http://ccnetlive.thoughtworks.com/MSBuildXmlLogger-Builds实验：我们可以先将解决方案中bin\debug中生成的dll删除，然后强制build，就会重新生成一个dll。
这里我们可以在写一个<msbuild/>去编译另一个解决方案，也可以将所有要编译的解决方案放入一个文件夹下面。然后修改projectFile节点如下：<projectFile>Solution"*.sln</projectFile>这样的形式（我没有试过，网上有这样的示例，大家可以试试）。
编译成功后，当然是进行单元测试了。
脚本如下：
<nunit>
<path>F:\Test\CITest\NUnit-2.4.8-net-2.0\bin\nunit-console.exe</path>
<outputfile>F:\Test\CITest\nunit-results.xml</outputfile>
<assemblies>
<assembly>F:\Test\CITest\Code\TestProject\bin\Debug\test.dll</assembly>
</assemblies>
</nunit>
将脚本添加到tasks节点中，位于msbuild的下面。
说明：
path：nunit-console.exe的路径，位于NUnit文件夹下的bin目录中。
Outputfile：单元测试输出的结果文件（文件名可以修改）
Assembly:要进行单元测试的dll或者exe文件的路径。
脚本编写完后，重启服务，然后强制build，当成功后，会在F:\Test\CITest目录下产生一个名 “nunit-results.xml”的文件。同时，我们双击CCTray右面的Project,就会打开webdashboard，通过它我们就可以浏览刚刚的编译成果。如图：
双击后，弹出窗体：
然后点击here，
这就是，我们刚刚进行过单元测试的结果。请看框选的部分。如果没有进行单元测试，结果是这样的,如图： 
这样结果就很显然了。
现在我们已经在tasks节点下配置项目编译工具如msbuild，nunit，我们还可以用nant
脚本如下：
<nant>
<executable>F:\Test\CITest\nant-0.85\bin\nant.exe</executable>
<baseDirectory>F:\Test\CITest</baseDirectory>
<buildArgs></buildArgs>
<nologo>false</nologo>
<buildFile>default.build</buildFile>
<logger></logger>
<targetList>
<target>run</target>
</targetList>
<buildTimeoutSeconds>1200</buildTimeoutSeconds>
</nant>
说明：
baseDirectory：default.build文件所在的路径
buildArgs
nolog
logger
targetargetList名称
buildTimeoutSeconds
这样，我们就成功的用CC.NET调用了NAnt。我们可以在NAnt去做另外的操作。有关NAnt的使用请参阅““。
使用方法：
<exec>
<executable>C:\Program Files\NCover\NCover.Console.exe</executable>
<baseDirectory>F:\Test\CITest</baseDirectory>
<buildArgs>F:\Test\CITest\NUnit-2.4.8-net-2.0\bin\nunit-console.exe /noshadow F:\Test\CITest\Code\TestProject\bin\Debug\test.dll</buildArgs>
</exec>
说明：
本例就是通过外部的NCover.Console.exe去调用了NUnit-console.exe，然后对test.dll，进行了代码覆盖率的检查。
前面我们都是通过强制build对项目进行的build，现在我们介绍一下触发器。
触发器必须配置在<triggers>中，并且它可以嵌套。
可以屏蔽其它触发器，使其它触发器不执行。
<filtertrigger startTime=”7:30” endTime=”12:00”表示在每天的上午7:30到12:00都不执行持续集成。
注：嵌套在触发器里面的触发器，格式一定要是这样：<trigger type=”intervaltrigger”/>
例如：
<filterTrigger startTime="23:30" endTime="23:45">
<trigger type="intervalTrigger" seconds="60" />
<weekDay>Sunday</weekDay>
</filterTrigger>
说明：
weekDays：可以显式指定在一周的哪些天该触发器有效，默认是一周七天
<intervaltrigger seconds=”30” buildCondition=”ForeBuild”/>
说明：
Seconds：两次执行之间的间隔，默认为60秒
buildCondition：可以指定什么条件下该触发器才有效
IfModificationExists:指当CC.NET请求版本库中有修改的时候才执行。
定期触发器，可以设置一天中的一个时间定期的去执行持续集成
<scheduleTrigger time="23:30" buildCondition="ForceBuild" >
<weekDay>Monday</weekDay>
</scheduleTrigger>
说明：
并列定义多个触发器，用逻辑关系去设定它们。
<multiTrigger operator="And">
<intervalTrigger />
<filteredTrigger startTime="23:30" endTime="23:45" />
</multiTrigger>
说明：
有兴趣的朋友可以分别试试这些。
使用什么样的方式标识每一个自动生成的版本，可以有多种不同的方式。Labeller Blocks
如果设置成<labeller type="defaultlabeller">
<prefix>Foo-1-</prefix>
<incrementOnFailure>true</incrementOnFailure>
<labelFormat>00000</labelFormat>
</labeller>
mailhostUsername="smtpuser" mailhostPassword="smtppassword" useSSL="FALSE">
<group notification="change"/>
<group notification="always"/>
<modifierNotificationTypes>
<NotificationType>Failed</NotificationType>
<NotificationType>Fixed</NotificationType>
</modifierNotificationTypes>
</email>
说明：
mailhost:CC.NET将要连接的SMTP服务器进行发送邮件
mailport: SMTP服务器的端口
includeDetails：是否发送一个完整的信息，true发送完整的信息。False，仅发送一个简单的状态信息
mailhostUsername这个邮件地址的用户名。
mailhostPassword：提供SMTP服务器的密码.
useSSL:是否用SSL发送邮件
users：定义一系列的user元素，用来发送邮件给他们
user：
groups：定义一系列的group，根据不同的通知策略进行通知
group：
name：group的名字，与user中的group相对应
notification：但某种情况下发送邮件
type：
Always：只要有build发生就发送
Change：当build的状态发成改变时发送（从“成功”到“失败”）
Failed：当build失败时发送
Success：当build成功是发送
Fixed: 当build的状态发成改变时发送（从“失败”到“成功”）
converters: 一套包含的内容规则创造的电子邮件地址基础上修饰的名称。
转换时将使用的名称修饰是没有设置的用户一节。(不是很了解)
modifierNotificationTypes：同group中的notification一样，但是用法不知道是做什么用的?有知道的朋友告诉我一下。