Friday, April 27, 2007

CC.Net - Project Report Page

In CC.Net, the Project Report page provides general information for a project.



Most of the items should be straightforward. One thing you may notice is that the "View Statistics" link doesn't work. Clicking the link gives an exception page stating "Object reference not set to an instance of an object." The problem is that the <statistics> publisher wasn't specified. Add the following to ccnet.config, within <project></project>

    <publishers>
<statistics/>
</publishers>
Reload the page... "Unexpected exception caught on server." The other pages now fail with the same error. Not exactly the desired results. Digging through the exception details, it appears the Log Publisher is missing. Yet it was there a minute ago?

It turns out a default publisher is used if one isn't specified. You can see this by removing the <publishers> section and clicking Project Configuration on the left. This page gives the project's entire XML listing, both the entries in ccnet.config and any defaults you don't override. A useful addition.

Anyway, the publisher error is a simple fix:

    <publishers>
<statistics/>
<xmllogger/>
</publishers>

The pages again load. On top of that, we now have statistics. Or, will, as soon as we run another build. Force a build, and you should see basic stats for the project.


Nothing fancy, but it's a start.

One more useful feature is the External Links item. With this, you can easily add links to other resources - project documentation, bug server, etc. Again, this is added within <project></project>

    <externalLinks>
<externalLink name="Project Documentation" url="\\fileserver\project1\project.doc" />
</externalLinks>

Wednesday, April 25, 2007

CruiseControl.Net 101 - Projects

Last time, we installed CC.Net and created a blank project. This time, we'll have that project actually *do* something.

The first thing we need is something in source control to point to. I happen to have a SourceSafe database at c:\vss, so I'll use that. In SourceSafe (SS), I've created a new project, MSBuild.Chainsaw.Tasks. There aren't any files in there currently, but we'll get to that shortly. For now, let's add the following to ccnet.config, between the <project></project> tags:


<sourcecontrol type="vss" autoGetSource="true">
<ssdir>c:\vss</ssdir>
<executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
<project>$/MSBuild.Chainsaw.Tasks</project>
<workingDirectory>MSBuild.Chainsaw.Tasks</workingDirectory>
</sourcecontrol>

This tells CC.Net to monitor the project $/MSBuild.Chainsaw.Tasks and any sub-projects. If files are added or checked into the project, CC.Net will kick off a build. At this point, we should test the updated project.

Start Visual Studio 2005 (VS2005) and create a new C# Windows Class Library. Give it a name of MSBuild.Chainsaw.Tasks. Do not check the boxes to "Create directory for solution" or "Add to Source Control." The former is unnecessary, the later would ruin my cleverly devised plan. Once the project is generated, save the files and close VS2005. Nope, we're not actually writing code. We'll have to save that for another time.

Back in SS, drag the solution file into $/MSBuild.Chainsaw.Tasks. Open the CCTray app. You should see the Last Build Label increment (CC.Net looks for changes once a minute, so you might have to wait a few seconds.) The build still shows green - we haven't specified any tasks to perform. Open Windows Explorer and browse to your CC.Net install folder. Expand \server\Project 1\WorkingDirectory\MSBuild.Chainsaw.Tasks. You should see the .sln file, meaning it's at least pulling the source correctly.

To compile with MSBuild, there is one more piece we need. By default, msbuild sends text output to the console. CC.Net requires XML output from all of the build tasks. You'll need to download ThoughtWorks.CruiseControl.MSBuild.dll. Out of shear laziness, I place this file in the root of the c: drive.

With that out of the way, let's go back to ccnet.config. Add the following to the file:


<tasks>
<msbuild>
<executable>c:\winnt\Microsoft.Net\Framework\v2.0.50727\msbuild.exe</executable>
<projectFile>MSBuild.Chainsaw.Tasks\MSBuild.Chainsaw.Tasks.sln</projectFile>
<buildArgs>/noconsolelogger </buildArgs>
<logger>c:\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
</tasks>

Note: The <executable> tag is necessary if you're running on Windows2000. If you're on WinXP, it isn't required.

Save the config and go back to CCTray. Hmm... Nothing happened. That's of course by design - nothing's changed in SS. To test the config change we need to force a build. This can be done with the Force button in the Dashboard, or by right-clicking the project in CCTray and choosing Force Build.

After the build runs, the CCTray icon will be red. In the Dashboard, the Last Build Status shows "Failure." To look at the details, open Project 1 in the Dashboard. Select the most recent build. The Build Report for this build doesn't tell us much (we'll fix this shortly.) Click "View Build Log" from the menu on the left. This is the raw XML output from the build. If you look in the <msbuild> section, you should see a line that includes 'The project file "MSBuild.Chainsaw.Tasks.csproj" was not found.' Not surprising since we didn't add it to SS yet.

Before we fix this error, let's modify the report to show MSBuild output. In Windows Explorer, browse to \webdashboard in the install folder. Open dashboard.config. Locate the following:


<buildPlugins>
<buildReportBuildPlugin>
<xslFileNames>
<xslFile>xsl\header.xsl</xslFile>
<xslFile>xsl\modifications.xsl</xslFile>
<xslFile>xsl\compile.xsl</xslFile>

Beneath this, add the line:


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

This will format msbuild output within the build report. Note that the ordering of the .xsl files determines the ordering in the report. Also, if there are items you aren't interested in, those lines can be removed from the config.

After you save the config, force another build and verify that you now have two additional sections in the Build Report - Errors and Warnings.

Now to fix the build error. Add the remaining files from the MSBuild.Chainsaw.Tasks project to SS. Having done that, we wait patiently while CC.Net kicks off another build. Assuming all the files were added, the build should complete successfully.

Sorry for the lengthy post. I could have stopped somewhere in the middle, but the one thing I can't stand is a broken build. My co-workers can attest to this.

Friday, April 20, 2007

CruiseControl.Net 101 - Installation

My plan is to start with few entries covering the basic setup, configuration and usage of CC.Net. This way, if I'm hit by a bus, someone else at work can take over as the BuildGuy. Or they can wipe the machine and turn it into an mp3 server. Their choice.

The server install (v1.2.1) is rather straightforward, though you'll want IIS loaded beforehand. During the install, check the boxes to install as a service, and to create a virtual directory in IIS. Note the service (CruiseControl.NET Server) is set to Manual startup, and eventually needs to be switched to Automatic. While configuring projects, however, you may find it easier to debug running the console.

Once installed, start the console or service and point your browser to http://localhost/ccnet/. If the Dashboard is displayed, good job. Your install went smoother than mine. Because I installed IIS after the .NET framework, I received an error stating "Failed to access IIS metabase." Running "aspnet_regiis -i -enable" took care of the issue.

Now that we have the server running, we need a project. Open ccnet.config - located in "C:\Program Files\CruiseControl.NET\server" on my box. Replace the contents with:

<cruisecontrol>
<project name="Project 1">
</project>
</cruisecontrol>

No, it doesn't do anything - I'm not in any hurry. Save the file and go back to the Dashboard. You should now see "Project 1" in the list.

With that in place, install the CC.NET TrayApp. One installed, we want to add Project 1 to the list of monitored projects. In CCTray, go to File > Settings. On the Build Projects tab, click Add. Click Add Server. The Build Server dialog now visible provides three methods of connecting to the server. Either the dashboard or remoting options will work.

Once you've selected a connection method, the Project list now contains the build server and a single project (Project 1.) Select the project and click OK. Click OK to close the settings, and you should now see the status of the project. This will match the info displayed on the Dashboard.

Well, that was fun. Maybe next time we'll have the server do something useful. But I make no promises...