CruiseControl.NET : FAQ
This page last changed on Nov 16, 2010 by williams.
This is the CruiseControl.NET Frequently Asked Questions (FAQ)
This FAQ is not meant to be a complete reference to CruiseControl.NET, but does provide some quick ideas about how to get various things done.
If you want to add questions, answers, or both, please use the ccnet-user mailing list
When I run the installers, McAfee VirusScan 8.0 is popping up a dialog reporting problems with 'nsScm.dll'.
The 'nsScm.dll' is a library supplied by the NullSoft installer for installing services. There is no virus in this dll. The easiest way to proceed with the installation is to uncheck the "Install CCService" checkbox and install CCService manually once the installer has completed.
In the ccnet.config file, you need to move your Merge Task section from the Tasks Block to the Publishers Block. The reason is that the first task to fail in the tasks section will prevent any further tasks from being run. If this task is your Merge Task then your test result files will not be included in the build. All tasks in the publishers section will run regardless of whether previous tasks succeed or fail.
CCNet sometimes throws an exception during a task, but there's no information in the log about where the task triggered the exception?
This can happen, for example, if a task times out. A good practice that helps in these situations is to specify an explicit task-level log file for each task, different for each task. If CCNet fails to merge in that log file, then at least you can check the actual log file before it's been merged. (Also, see the preceding FAQ about merging output from failed tasks.)
For example, with a NAnt task you could use:
Then if the task crashes and CCNet doesn't merge in the NAnt log file, you can go to projecta.targetx.log.xml in the working directory, to see the original output from NAnt.
CCNet integrates with external applications via the command-line, hence it is essential that the command executed by CCNet is correct for everything to work:
Many of the examples on the mailing list and user's blogs showing how to use information from the server (such as the build label) are based on the NAnt Task, and date from before the first release candidate. Around that time, most of the property names changed, for example ccnet.label became CCNetLabel. Check the documentation page for the task you are using (ideally the one installed on your machine which should be accurate for the build of CruiseControl you installed) and make sure your build script is using the correct name for the property.
According to the documentation, I need file xxxxxxxx.yyy. That file isn't in the distribution, where do I find it?
It's likely that you have fallen into the classic mistake of overlooking that the documentation on the web site relates to the most recently built version, not the most recently released one. If the file in question is referenced in the /doc folder of your CCNet installation then ask on the CCNet user mailing list - you have probably found a documentation problem. If the file is not referenced in that folder, but is referenced in the online documentation you may want to try a more recent build from http://ccnetlive.thoughtworks.com/. If you choose to do so, please be aware that builds from CCNetLive may contain more bugs than officially released versions of CCNet.
When triggering external tools like NAnt, MSBuild and even Devenv CruiseControl.Net uses the "ErrorLevel" exit value returned by the tool to determine if the process was successful. In most such tools, zero is returned if the task succeeded. A non-zero value is typically used to indicate a failure, and when it sees a non-zero value CCNet will report that the task failed.
If the tool you are using does not respect these conventions (like, for example, Microsoft's FXCop utility), then CruiseControl may report failure (or success) incorrectly.
The easiest way to find out what ErrorLevel is returned by the tool is to use a small batch file like this:
Run the batch file from a command prompt and check the response. This should confirm if the problem is that the tool is returning the wrong value (most likely) or you have found a bug in CruiseControl.Net.
Some users have reported that occasionally even though the return value can be confirmed as non-zero using the command prompt it is not recognised as a failure by CruiseControl.Net. It may be possible to work-around this is as follows:
If you have introduced errors to your config file CruiseControl.NET will fail to load, and keep using the already loaded old configuration. So check the log, or stop the service and run the commandline tool to fix the configuration problem.
The exact sequence of operations is:
1) Wait for the triggers to awaken.
You will get these warnings if your ccnet.config file contains invalid elements or attributes. Please double check the documentation that came with your installation (in the /doc folder). Please be aware that the documentation on the web site may reflect a more recent version of ccnet than what you have installed. If you are attempting to use a task or a property that has not been implemented in your server's version of ccnet then you will get this error.
I get the error "INTERNAL ERROR: ExpandableObjectConverter cannot convert from System.String." when using <sourcecontrol type="multi">
This error occurs if you try and use a <sourcecontrol> block inside a Multi Source Control Block. The name of the element should instead be the same as you would put in the "type" attribute when using a <sourcecontrol> element. For more information and an example, see Multi Source Control Block.
Properties as in Nant or MSBuild (e.g., "$(workingDirectory)") are supported from CCNet version 1.4RC1 and upwards. See the Configuration Preprocessor documentation for more details.
My build can't find environment variables when run from the service, but it works fine manually or from the ccnet command line server
You may be running the CCNet Service under the SYSTEM account, or some different account other than your own. Many environment variables under MS Windows are set on a per-user basis, which means that the SYSTEM account won't have the same variables as you. Depending on the circumstances, you might want to move those environment variable definitions to be system-wide. Another alternative is to run the service under your account, or create a separate build account for use by CC.Net. Finally, some tasks such as NAnt can explictly create environment variables for themselves (but these won't be passed on to other CruiseControl.Net tasks).
Problems with ccservice.exe that don't happen with ccnet.exe almost always come back to one of two things:
Why is the vss source control block throwing errors when CCNet is running as a service but works when running CCNet from the command line?
In order to access VSS, you must be able to access the shared folder on your VSS server from your CCNet server. The CCNet service is set to use a local system user account by default which doesn't have access to other machines. In order for CCNet to access VSS, you must change the log account for the service to a user that has network access to the VSS machine. More details can be found in the Service and Visual Source Safe Source Control Block sections.
My build process updates one or more files under source code control. CruiseControl.NET then thinks my code has changed and rebuilds again. How do I stop this cycle?
This problem is most commonly associated with updating AssemblyInfo.cs (or similar) files containing build-specific information.
The simplest solution is to ensure that these files are not placed under source control, but are always generated at build time. Unfortunately, this may not always be an appropriate way to resolve the problem. In such circumstances, you may want to use a Filtered Source Control Block to exclude the files modified during the build process.
Use an empty <triggers /> tag in your config file. Read more at Trigger Blocks.
One of the principles of Continuous Integration is that build failures are reported as quickly as possible. This means that if any item in the <tasks> section of the Project Configuration Block reports a failure CruiseControl.Net will skip the remaining tasks and continue to the entries in the <publishers> section. If you need to do something more complex, we recommend using a tool like NAnt or MSBuild to handle the build tasks. An example showing how to use NAnt and NUnit to execute multiple test fixtures can be found on the Using CruiseControl.NET with NUnit page.
You can use the Integration Queues support. If you place more than one project in the same queue, CruiseControl.Net will ensure that only one of them runs at a time.
If you installed IIS after the .Net framework was installed, you need to register ASP.Net with IIS. You can do this by running the aspnet_regiis.exe tool found under \Windows\Microsoft.NET\Framework\v2.0.50727\
The look and feel of the Dashboard is defined by the velocity templates and xsl files in the templates and xsl sub-folders of your Web Dashboard folder (which by default is at C:\Windows\Program Files\CruiseControl.NET\webdashboard .)
Both the Build Report Build Plugin and XSL Report Build Plugin can be configured to use custom stylesheets. Change the configuration of the Build Report Build Plugin if you want to add a stylesheet to the main Build Report, or add a new XSL Report Build Plugin instance if you want a totally new page for the report.
If the tool creates an result file, use the merge filetask to get it into the build result. (mostly done in the publisher section). If the result file is XML, the handling goes a lot easier.
How do I prevent all these unwanted messages from showing up in the warning/error sections of the WebDashboard?
When executing external processes, CCNet will identify any output written to the standard error stream in the error or warnings section of the WebDashboard. To supress these messages, you can redirect the stderr stream to stdout as shown in the example below. '2' refers to stderr and '>&1' redirects it to stdout ('&1').
I get the following error in the web dashboard: "Ticks must be between DateTime.MinValue.Ticks and DateTime.MaxValue.Ticks. Parameter name: ticks"
You will get this error if your CCNet server is running under the .NET 2.0 framework, whereas the webdashboard or CCTray is running under version 1.x. This is a problem using .NET remoting across different versions of the .NET framework. You can fix this by ensuring that you are using the same version of the .NET framework for the CCNet components (CCTray, the CruiseControl.NET Server, and the Web Dashboard) on all machines.
If you have multiple versions of the .NET framework installed, you can select the version of the framework used by the web dashboard as follows:
add the following element to the httpHandlers in web.config
Standard CCNet will show basic information in which stage of the build it is :
This can be extendended, for Nant and MSBuild look at Viewing build progress with Nant and MSBuild in the Contribution section.
Standard CCNet will show basic information in which stage of the build it is :
This can be extendended, for Nant and MSBuild look at Viewing build progress with Nant and MSBuildin the Contribution section.
You need to install the Speech software SDK from Microsoft
WinXP SP1 has it by default, earlier windows versions must install it separately
|Document generated by Confluence on Jan 23, 2011 08:52|