The root element for a CruiseControl.NET server configuration. Defines a security manager implementation that implements security with configuration in external files. Defines a security manager implementation that implements security internally \- the security settings are stored in the same configuration file. A default implementation of a security manager where there is no security (e.g. every right is allowed); A build project. Configure the behaviour of the build queues. Defines a preprocessor constant. Controls the scope of preprocessor definitions. The files to load. The external file to import. The associated session cache. The audit loggers. The audit reader. The default permissions. The channel security requirements. The users for the same. The server-level permissions. The associated session cache. The audit loggers. The audit reader. The default permissions. The channel security requirements. Stores a user name - authentication will come from Active Directory. User password authentication checks that the user name and password combination is valid. User name authentication checks that the user name is valid. The AD domain to use. The user name for this user. The password for this user. The display name for this user. The name for this user. The display name for this user. The login name for this user. The location where the backing files are stored. If this is a relative folder, it will be relative to the program data folder for CruiseControl.NET. The duration, in minutes, that a session is stored for. The type of expiration period to use. Options are either Sliding (the expiry time is moved every time a security request is made) or Fixed (expiry time never changes). The duration, in minutes, that a session is stored for. The type of expiration period to use. Options are either Sliding (the expiry time is moved every time a security request is made) or Fixed (expiry time never changes). Sends audit logging information to a file. The information will be stored in an XML format. The location to log the audit events. Whether to log successful events or not. Whether to log failed events or not. The location of the file to read the audit events from. Defines how duplicates should be handled. A comma sperated list of queue names that the queue should acquire a lock against. The projects that are associated with this queue. A build project. Controls the scope of preprocessor definitions. The name of the queue. A set of Tasks to run before the build starts and before the source is updated. A failed task will fail the build and any subsequent tasks will not run. Tasks are run sequentially, in the order they appear in the configuration. Any security for the project. Dynamic build parameters - these are parameters that are set at build time instead of being hard-coded within the configuration file Links for this project to other sites. A state manager for the project. The type of data storage to use for the project. A reporting URL for this project. This is used by CCTray and the Email Publisher. Typically you should navigate to the Project Report on the Dashboard, and use its URL. An optional impersonation account. The maximum amount of source control exceptions in a row that may occur, before the project goes to the stopped state(when stopProjectOnReachingMaxSourceControlRetries is set to true). Stops the project on reaching maxSourceControlRetries or not. When set to true, the project will be stopped when the amount of consecutive source control errors is equal to maxSourceControlRetries. What action to take when a source control error occurs (during GetModifications). The name of the integration queue that this project will use. By default, each project runs in its own queue. The priority of this project within the integration queue. If multiple projects have pending requests in the specified queue then these requests will be executed according to their priority. Lower priority numbers indicate that integration requests for this project will execute before other projects in the same queue, however projects with priority 0 are always executed after projects with non-zero priorities in the same queue. The source control block to use. The list of build-completed publishers used by this project. The minimum number of seconds allowed between the last check in and the start of a valid build. Labellers are used to generate the label that CCNet uses to identify the specific build. The label generated by CCNet can be used to version your assemblies or label your version control system with each build. A set of Tasks to run as part of the build. A failed task will fail the build and any subsequent tasks will not run. Tasks are run sequentially, in the order they appear in the configuration. Sets the state of the project when CCNet service/Console starts. Stopped can be handy when you are adding a lot of projects which are depending on other projects (via the project trigger) and these may not be build right away. This value is only used when startupMode is set to UseInitialState. The start-up mode for this project. An optional description of the project. A general category for this project. This is used by the dashboard to provide groupings to the project. Categories do not span servers. Trigger blocks allow you to specify when CruiseControl.NET will start a new integration cycle. 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. Make sure this folder us unique per project to prevent problems with the build. You don't need to quote the Working Directory, even if it contains spaces. 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, distributables, etc. Make sure this folder us unique per project to prevent problems with reporting about a build. You don't need to quote the Aftifact Directory, even if it contains spaces. Each of these are used to display project related links on the project report page of the Web Dashboard, and are meant as a convenient shortcut to project-related web sites outside of CruiseControl.NET. Should a reason be requested when a force build is triggered. The name of your project - this must be unique for any given CruiseControl.NET server. This will prompt the user to enter a boolean value when a force build is requested. This parameter can then be used by a dynamic value in a task. This will prompt the user to enter a date value when a force build is requested. This parameter can then be used by a dynamic value in a task. This will prompt the user to enter a numeric value when a force build is requested. This parameter can then be used by a dynamic value in a task. This will prompt the user to select a value from a list of values when a force build is requested. This parameter can then be used by a dynamic value in a task. This will prompt the user to enter a text value when a force build is requested. This parameter can then be used by a dynamic value in a task. Is the parameter required? The value to use when the parameter is true. If the name attribute is set, then the user will see that as the selection value. Otherwise the actual value will be displayed. The value to use when the parameter is false. If the name attribute is set, then the user will see that as the selection value. Otherwise the actual value will be displayed. The display name of the parameter. The description of the parameter. The default value to use. The name of the parameter. The mimimum allowed value of the parameter. The maximum allowed value of the parameter. Is the parameter required? The display name of the parameter. The description of the parameter. The default value to use. The name of the parameter. The mimimum allowed value of the parameter. The maximum allowed value of the parameter. Is the parameter required? The display name of the parameter. The description of the parameter. The default value to use. The name of the parameter. Is the parameter required? Load the values from a file. An array of allowed values. The default value to use. The display name of the parameter. The description of the parameter. The name of the parameter. The minimum allowed length. The maximum allowed length of the parameter. Is the parameter required? The display name of the parameter. The description of the parameter. The default value to use. The name of the parameter. Major number component of the version. Minor number component of the version. Build number component of the version. If not specified the build number is incremented on every successful integration. Revision number component of the version. If not specified the revision number is the LastChangeNumber, provided by some VCS (e.g. the svn revision with the Subversion task). Whether to increase the build number component if the integration fails. By default the build number component will only increase if the integration was successful. The dynamic values to use for the labeller. The format for the year part. The format for the month part. The format for the day part. The format for the revision part. The dynamic values to use for the labeller. Any string to be put in front of all labels. Any string to be put at the end of all labels. Allows you to set the initial build number. If true, the label will be incremented even if the build fails. Otherwise it will only be incremented if the build succeeds. A format applied to the buildnumber. The dynamic values to use for the labeller. The pathname of the file to read. This can be the absolute path or one relative to the project's working directory. Any string to be put in front of all labels. Controls whether duplicate labels are permitted or not. If true, duplicate labels are left intact. If false, the label will be suffixed with "\-n", where "n" is incremented for each successive duplication. Defaults to "true" The dynamic values to use for the labeller. The duration of the iteration in weeks. The start date for the release (the start date of iteration one). The separator between the iteration number and the build number. Any string to be put in front of all labels. Any string to be put at the end of all labels. Allows you to set the initial build number. If true, the label will be incremented even if the build fails. Otherwise it will only be incremented if the build succeeds. A format applied to the buildnumber. The dynamic values to use for the labeller. The string to be prepended onto the last change number. Controls whether duplicate subsequent labels are permitted or not. If true, duplicate labels are left intact. If false, the label will always be suffixed with ".n", where "n" is incremented for each successive duplication. Defaults to true. The dynamic values to use for the labeller. The URI to the remote cruise server containing the project to use (defaults to the local build server). The project to retrieve the label from. The dynamic values to use for the labeller. The project to retrieve the label from. The dynamic values to use for the labeller. The default right to use. The allowed permissions. The name of the account to use for guests. The name of the account to use for guests. Source control integration for Accurev's source control product (http://www.accurev.com). Source control integration for the Alienbrain source control product. Source control integration for the BitKeeper source control product. Rational ClearCase source control block. Please refer to [Using CruiseControl.NET with CVS] for an overview of this block. For CVS you must define where the CVS executable (if you give a relative path, it must be relative to the ccnet.exe application) is and the working directory for checked out code. A source control implementation for use when the source control system doesn't integrate directly with CCNet. Use the 'Filesystem' Source Control plugin to check for modifications on a directory accessible by the build server. A file is considered modified if the file's modified time stamp is more recent than the last time CruiseControl.Net checked for modifications. You can use either directories on 'mapped' drives (local or remote), or UNC paths (remote). The FilteredSourceControl allows you to filter out modifications that are used to trigger a build. If for example, you have certain files (such as web pages or document files) under source control that you don't want to have trigger the build, you can use this class to ensure that their changes will keep a new build from launching. The FilteredSourceControl works together with all of the source controls supported by CCNet (including the [Multi Source Control Block]). It can also be included under the [Multi Source Control Block] provider so that you could have multiple FilterSourceControls each filtering a different set of modifications from different source control providers. Essentially, it acts as a decorator (or an example of the pipes and filters pattern ), wrapping around the specific SourceControl provider that you want to use. The FilteredSourceControl includes both inclusion and exclusion filters for specifying what modifications should be included/excluded. Multiple inclusion and exclusion filters can be specified or, alternately, no inclusion or exclusion filter could be specified. If a modification is matched by both the inclusion and exclusion filter, then the exclusion filter will take preference and the modification will not be included in the modification set. It is relatively straightforward to build new filters, (such as one to filter modifications based on email address). The Ftp Soure control block allows to detect new and changed files at an Ftp site. Deleted files are *NOT* detected. Source Control Plugin for CruiseControl.NET that talks to git. Provides basic support for Mercurial repositories. Checking for changes, checking out or updating sources, and tagging are supported. MKS Source Integrity Source Control Block. You can use the 'Multi' Source Control plugin to check for modifications from any number of source control repositories. You may want to do this if (for example) you want to build if the source for your project changes, or if the binaries your project depends on change (which may be stored on a file server). Use the Null Source Control if you don't want to check a Source Control repository for changes. In this instance you would always want to either use a 'Force Build' Trigger or always manually start builds, from the [Web Dashboard] or [CCTray]. Perforce source control block. This supports Códice Software's Plastic SCM source control system. CruiseControl.NET supports integrating with the PVCS Source Control system via the pcli client. Uses RoboCopy as Source Control. Source Controller for StarTeam SCM. Source Controller for Seapine Surround SCM The Seapine Surround provider is designed to work with Surround 4.1. It may not work with earlier versions of Surround. CruiseControl.NET provides basic support for Subversion repositories. Checking for changes, checking out or updating sources, and tagging\-by\-copying are supported, but more advanced features such as using Subversion revision numbers are not yet supported. Subversion support is under active development and will improve over time. CruiseControl.NET SCM plugin for CM Synergy. Detection of modifications is entirely task based rather than object based, which may present problems for pre\-6.3 lifecycles. Successful integration may be published through shared manual task folders and/or baselining. SourceGear Vault Source Control Block. For Visual Source Safe you must specify the executable, project, username and password. You may also specify the SSDIR. If SSDIR is not set the default or the SSDIR environment variable will be used. Source Control Plugin for CruiseControl.NET that talks to VSTS Team Foundation Server. Alienbrain server hostname or ip adress. The list of valid server name and ip adresses are listed in the File, Connect to project database, Step 1, list box. Alienbrain project database name. The list of valid project databases are listed in the File, Connect to project database, Step 2, list box. The name of the user you want to use to connect to the server project database. The password of the user you want to use to connect to the server project database. The path of the branch specification. to enumarate the name of the branches, use the ab enumbranch command line. This is the path of to monitor the file changes. Use alienbrain://Code or ab://Code project path format. Specifies whether the current version of the source should be retrieved from Alienbrain. The path where the get latest will update the files. Specifies whether or not the repository should be labelled after a successful build. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. The executable to use. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. Specifies whether the current version of the source should be retrieved from AccuRev. Specifies the path to the AccuRev command line tool. You should only have to include this element if the tool isn't in your path. By default, the AccuRev client installation process names it accurev.exe and puts it in C:\Program Files\AccuRev\bin. Specifies the location of the AccuRev home directory. The pathname can be either absolute or relative to the project artifact directory. If not specified, AccuRev will follow its rules for determining the location. The home directory itself is always named ".accurev". Specifies whether or not CCNet should create an AccuRev snapshot when the build is successful. If set to true, CCNet will create a snapshot of the workspace's basis stream as of the starting time of the build, naming it according to the build label. Specifies whether or not CCNet should log in to AccuRev using the specified principal and password. If set to true, the principal and password elements are required, and CCNet will use them to log in to AccuRev before executing any AccuRev commands. Specifies the password for the AccuRev "principal" (userid). Specifies the AccuRev "principal" (userid) to run under. If not specified, AccuRev will follow its rules for determining the principal. Specifies the location on disk of the AccuRev workspace that CCNet monitors for changes. The pathname can be either absolute or relative to the project working directory, and must identify the top\-level directory of the workspace. Note that this is not the same as the workspace name \- AccuRev will determine the workspace name from the disk pathname. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. Absolute, DOS\-style, path to bk.exe. Absolute, DOS\-style, path to permanent BK repository. Add BK tag on successful build. Automatically pull latest source into permanent BK repository. Include history of each file, rather than just ChangeSets. Make a clone of the permanent BK repository into the designated path. The DOS\-style path can be relative to WorkingDirectory or absolute. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. Specifies the path to the ClearCase command line tool. You should only have to include this element if the tool isn't in your path. By default, the ClearCase client installation puts cleartool in your path. The name of the project VOB that the view path uses. Specifies whether a baseline should be applied when the build is successful. Requires the VOB your view references to be a UCM VOB. Specifies whether a label should be applied when the build is successful. The name of the view that you're using. The path that CCNet will check for modifications and use to apply the label. Specifies whether the current version of the source should be retrieved from ClearCase. The name of the branch that CCNet will monitor for modifications. Note that the config spec of the view being built from must also be set up to reference this branch. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The location of the cvs.exe executable. The cvs connection string. If this is unspecified and your working directory contains a previous checkout, then the CVS client will attempt to determine the correct root based on the CVS folder in your working directory. If the working directory does not contain the source, then this element must be specfied. The cvs module to monitor. This element is used both when checking for modifications and when checking out the source into an empty working directory. The folder that the source has been checked out into. Specifies whether or not the repository should be labelled after a successful build. Only list modifications checked in by specified logins. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details Specifies whether the current version of the source should be retrieved from CVS. Specifies whether or not a clean copy should be retrieved. Specifies whether the checkout command should be used instead of update. The branch to check for modifications on. By default the CVS tag name used when labelOnSuccess is set to true is ver\-BuildLabel. If you specify this property, the prefix ver\- will be replaced with the value you specify. Suppresses headers that do not have revisions within the specified modification window. Setting this option to true will reduce the time that it takes for CCNet to poll CVS for changes. Only fairly recent versions of CVS support this option. Run cvs \-\-help log to see if the \-S option is listed. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. A string to be passed to the external source control program in commands. Should we automatically obtain updated source from the source control system or not? A set of environment variables set for commands that are executed. Name of the source control system executable to run. If set, the source repository will be tagged with the build label upon successful builds. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. This element is used to specify the type of source control provider to retrieve modifications from. With the exception of the element name, the configuration for this element is identical to the xml configuration for the specific source control provider you intend to use. The list of filters that decide what modifications to exclude. The list of filters that decide what modifications to include. The dynamic values to use for the source control block. The directory to check for changes. This directory will be checked recursively. Whether to automatically (recursively) copy the contents of the repositoryRoot directory to the Project Working Directory. Whether to not fail if the repository doesn't exist. The dynamic values to use for the source control block. The name of the server to connect to. The user name to log in with. The password for the user. Whether to use active connection mode or not. The folder name of on the ftp site. The folder name on the local system. Whether to recurse into subfolders or not. The dynamic values to use for the source control block. Whether to fetch the updates from the repository and checkout the branch for a particular build. The location of the Git executable. The url to the remote repository. Remote repository branch to monitor and checkout. Format string for the commit message of each tag. \{0\} is the placeholder for the current build label. Format string for the name of each tag. Make sure you're only using allowed characters. \{0\} is the placeholder for the current build label. Indicates that the repository should be tagged if the build succeeds. Indicates that all modifications during the build process should be committed before tagging. This requires 'tagOnSuccess ' to be set to 'true'. Indicates that files created during the build process should be committed before tagging. This requires 'commitBuildModifications' and 'tagOnSuccess ' to be set to 'true'. Used to set the "user.name" configuration setting in the local repository. Required for the 'tagOnSuccess ' feature. Used to set the "user.email" configuration setting in the local repository. Required for the 'tagOnSuccess ' feature. The directory containing the local git repository. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. Whether to update the local working copy from the local repository for a particular build. Repository branch. The location of the hg executable. Should the build fail if the local repository has multiple heads? The url for your repository (e.g., http://hgserver/myproject/). String format for tags in your repository. Indicates that the repository should be tagged if the build succeeds. The directory containing the locally checked out workspace. Generates a web URL. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The local path for the MKS source integrity command\-line client (eg. c:\Mks\bin\si.exe). MKS Source Integrity user ID that CCNet should use. Password for the MKS Source Integrity user ID. Whether to set a checkpoint on success or not. Instruct CCNet whether or not you want it to automatically retrieve the latest source from the repository. The IP address or machine name of the MKS Source Integrity server. The port on the MKS Source Integrity server to connect to. The local path MKS Source Integrity sandbox root corresponds to. The project file. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. If true, only return a list of modifications if all sourceControl sections return a non\-empty list. Note that this is short\-circuiting, i.e. if the first sourceControl returns an empty list, the next won't be called (this can be useful for situations where you have a slow source control server and you want to check a specific file first as a trigger). The list of other Source Control Blocks to include. The dynamic values to use for the source control block. Defines whether or not to fail the checking for modifications. Defines whether or not to fail the labeling. Defines whether or not to fail the getting of the source. The location of the Perforce command line client executable. The perforce 'view' to check for changes. For 'multi\-line' views, use a comma\-separated list. 'Exclusionary' view lines starting with \- cannot be used. Use a [Filtered Source Control Block] to achieve this behaviour. Note that this view is not used for syncing (see below.) The perforce 'client' to use. The perforce user to use. The perforce password to use. The perforce hostname and port to use. The working directory to use. Whether to apply a label on a successful build. Whether to automatically 'sync' the latest changes from source control before performing the build. The sync target is the entire view exposed by the specified client \- the view has no effect on sycning. If autoGetSource is set to true, then whether to use the \-f option to sync. See http://www.perforce.com/perforce/doc.042/manuals/cmdref/sync.html for more details. Creates a link to the P4Web change list page for each detected modification. The specified value is transformed using String.Format where the first argument will be the substituted change list number. How many hours ahead your Perforce Server is from your build server. E.g. if your build server is in London, and your Perforce server is in New York, this value would be '\-5'. The error pattern to use. Whether to use exit codes. The acceptable errors. An acceptable error. Converts the comment (or parts from it) into an url pointing to the issue for this build. The dynamic values to use for the source control block. Should we automatically obtain updated source from PlasticSCM or not? Name of the PlasticSCM executable. The Plastic SCM branch to monitor. The Plastic SCM repository to monitor. Valid Plastic SCM workspace path. Specifies whether or not CCNet should create an Plastic SCM baseline when the build is successful. Specifies the prefix label name. Do the update with the "\-\-forced" option. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The PVCS client executable. The location of the PVCS project database. One ore more projects in PVCS that you wish to monitor. As long as each subproject is separated with a space and a "/", you can monitor more than one subproject at a time. Username for the user account to use to connect to PVCS. Password for the PVCS user account. The local directory containing the source from the repository. The workspace to use. Whether to monitor all subfolders of the specified subproject. Whether or not to apply a label to the repository after each successful build. Specifies whether the CCNet should take responsibility for retrieving the current version of the source from the repository. In PVCS 7.5.1, the client does not automatically adjust dates to accommodate daylight savings time. Setting this flag to true will make CCNet compensate for it. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. The label to use as your code\-base. If this is specified, this label will be called to get all code associated with it when a get is done. When the build is successful, the good code will have this base label associated with it in turn promoting it into the label. Label to apply to repository. If a value is specified, labelOnSuccess will automatically be set to true. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The executable location. The repository root. Whether to automatically get the source. The working directory to use. Any additional arguments. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. The local path for the StarTeam command\-line client (eg. c:\starteam\stcmd.exe). The StarTeam project (and view) to monitor (eg. project/view). StarTeam ID that CCNet should use. Password for the StarTeam user ID. The IP address or machine name of the StarTeam server. The port on the StarTeam server to connect to. The path to monitor. Instruct CCNet whether or not you want it to automatically retrieve the latest source from the repository. Instruct CCNet whether or not you want it to automatically retrieve the latest source from the repository. If set, use the \-rp option to use a different View Working Directory. Allows you to use your own RegEx to parse StarTeam's folder output. Allows you to use your own RegEx to parse StarTeam's file output. Allows you to use your own RegEx to parse StarTeam's file history. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The local path for the Surround SCM command\-line client (eg. C:\Program Files\Seapine\Surround SCM\sscm.exe). The Surround SCM branch to monitor. The Surround SCM repository to monitor. A filename pattern to match to monitor and retrieve files. The local path to get files from Surround SCM to. The IP address or machine name and port number of the Surround SCM server. Surround SCM login:password that CCNet should use. Treat the filename pattern as a regular expression. (Value 1 = true, 0 = false) Monitor and retrieve all files in child repositories of the specified repository. (Value 1 = true, 0 = false). Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The root url for the WebSVN site. The location of the svn executable. The url for your repository (e.g., svn://svnserver/). The directory containing the locally checked out workspace. Indicates that the repository should be tagged if the build succeeds. Should any detected obstructions be deleted prior to getting modifications? The base url for tags in your repository. The username to use for authentication when connecting to the repository. The password to use for authentication when connecting to the repository. Whether to retrieve the updates from Subversion for a particular build. Whether to check the paths specified in the svn:externals property for modifications. Whether to check for modifications of svn:externals recursively. Whether to delete the working copy before updating the source. Reverts any local changes to a file or directory and resolves any conflicted states. svn revert will not only revert the contents of an item in your working copy, but also any property changes. Finally, you can use it to undo any scheduling operations that you may have done (e.g. files scheduled for addition or deletion can be "unscheduled"). Recursively clean up the working copy, removing locks resuming unfinished operations. If you ever get a "working copy locked" error, run this command to remove stale locks and get your working copy into a usable state again. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. Whether to use revision numbers for fetching the modifications. Defines the auth caching mode to use. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The issue URL builder to use. Connection info to create a session. The info for the integration testing project. The Web Url builder to use. The dynamic values to use for the source control block. Hostname of the Synergy server Network path to the Synergy database instance Poll the server every minute when the ccm\_admin has protected the database for the purpose of issuing backup commands. The role to use for the Synergy session. Timeout in seconds for all Synergy commands. The executable filename/path for the CM Synergy command line interface. The directory to execute all CM Synergy commands from. The username for the Synergy session. Can include environmental variables to be replaced. The Synergy password for the associate value. The full physical path of the home directory for the associated Username on the client machine. Can include environmental variables to be replaced. Path for the remote client session to copy database information to. Can include environmental variables to be replaced. The configured Synergy release value for the given project. The configured Synergy project specification for all source control operations. The folder specification for the shared folder which will be used to "manually" add successfully integrated tasks added to. If true, creates a new baseline for the project configuration after a successful integration. If true, resets the reconfigure properties for this project and all subprojects to use the reconfigure template. If enabled, updates the work area from the database, discarding all uncontrolled files in the work area and changes to static objects. The file to reconcile. Synergy purpose specification for the project and any created baselines. Vault user id that CCNet should use to authenticate. Password for the Vault user. The name of the Vault server. The name of the Vault repository to monitor. . The root folder to be monitored by CCNet. The location of the Vault command\-line executable. Should SSL be used to communicate with the Vault server. Specifies if CCNet should automatically retrieve the latest version of the source from the repository. Specifies if CCNet should apply the build label to the repository. Extra arguments to be included in the history commandline. *CC.NET 1.0*: Determines the working directory into which Vault files will be retrieved. Supply true if you want CCNet to use the Vault folder working directory created for the build user using the Vault GUI (recommended). Supply false if CCNet should use the CCNet working directory. *CC.NET 1.1*: Determines if the source will be retrieved into a Vault Working Folder. The root folder where the latest source will retrieved from Vault. This path can either be absolute or it can be relative to the CCNet project working directory. The modification date that retrieved source files will have. If true, the source path will be emptied before retrieving new source. The host name of the HTTP proxy Vault should use. The port on the HTTP proxy Vault should use. The user name for the HTTP proxy Vault should use. The password for the HTTP proxy Vault should use. The Windows domain of the HTTP proxy Vault should use. Any other aruuments to pass into the executable. The number of seconds to wait between retries when a check for modifications fails. The number of automatic retries when failing to check for modifications before an exception is thrown. Sets the timeout period for the source control operation. The dynamic values to use for the source control block. The project in the repository to be monitored. VSS user ID that CCNet should use to authenticate. If the username is unspecified, the VSS client will attempt to authenticate using the NT user. Password for the VSS user ID. Specifies whether the current CCNet label should be applied to all source files under the current project in VSS. Specifies whether the current version of the source should be retrieved from VSS. Specifies whether the most recent version of the source should be retrieved from VSS. If not, CCNet will obtain the source as of the time the build began. The folder into which the source should be retrived from VSS. If this folder does not exist, it will be automatically created. Controls whether or not VSS gets a clean copy (overwrites modified files) when getting the latest source. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. The location of SS.EXE. If VSS is installed on the integration server, the location of VSS will be read from the registry and this element may be omitted. Password for the VSS user ID. The culture under which VSS is running. This value must match the culture of the VSS installation for CCNet to work with VSS. Most of the time the default is OK and you may omit this item. If you are using the US version of VSS on a machine that is not set to the US culture, you should include the configuration block <culture>en\-US</culture>. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. The name or URL of the team foundation server. For example http://vstsb2:8080 or vstsb2 if it has already been registered on the machine. The path to the project in source control, for example $\VSTSPlugins Whether this repository should be labeled. Whether to automatically get the source. Username that should be used. Domain cannot be placed here, rather in domain property. The password in clear text of the domain user to be used. The domain of the user to be used. The working directory to use. Whether to do a clean copy. Whether to force or not. Flag indicating if workspace should be deleted every time or if it should be left (the default). Leaving the workspace will mean that subsequent gets will only need to transfer the modified files, improving performance considerably. Converts the comment (or parts from it) into an url pointing to the issue for this build. See [IssueUrlBuilder] for more details. The path to the executable Name of the workspace to create. This will revert to the DEFAULT\_WORKSPACE\_NAME if not passed. Sets the timeout period for the source control operation. See [Timeout Configuration] for details. The dynamic values to use for the source control block. A URL builder to link each modification to the ChangeSynergy task details form. It contains the url of the involved project, with the issue number as a parameter. Build a Mercurial URL. This issue tracker allows a combination of the other issuetrackers. This will use regular expressions to convert the comment into an url. Generates a URL for ViewCVS. Generates a URL for WebSVN. Network path to the Synergy database instance The role to use for the Synergy session. The root path to the ChangeSynergy installation. The username to use for ChangeSynergy access. Can include environmental variables to be replaced. The Synergy password for the associate value. The base URL to use. The base URL to use. The issue trackers to combine. The string to find. The replacement string. The base URL. The base URL. The ActionFilter can be used to filter modifications on the basis of the type of modification that was committed. Modification types are specific to each source control provider. Consult each source control provider for the list of actions to filter. A FilteredSourceControl filter that compares modification comments to a specified regular expression. The PathFilter can be used to filter modifications on the basis of their file path. The UserFilter can be used to filter modifications on the basis of the username that committed the changes. The actions to filter. An action to filter. This is the pattern used to compare the modification comment against. The pattern is specified according to the rules of the .net System.Text.RegularExpressions.Regex class. Each CommentFilter contains a single pattern element. This is the pattern used to compare the modification path against. The pattern should match the path of the files in the repository (not the path of the files in the working directory). See below for examples of the syntax for this element. Each PathFilter contains a single pattern element. Sets casesensitive searching on or off. The user names to filter. The user name to filter. Profiles the performance of an application using Reg Gate's ANTS Performance Profiler. ANTS Performance Profiler is a tool to profile the performance of an application. This application is available from http://www.red\-gate.com/. Pro edition of 1.6 or later is required. The artifact CleanUp publisher allows for automatic removal of the buildlogs according to the choosen setting. It relies on the build log folder, so the XML publisher must be specified before this publisher can run. For technical reasons this publisher MUST reside in the publisher section, it will not work in the tasks section. Be sure to specify the [Xml Log Publisher] before this one. The Build Publisher lets you copy any arbitrary files on a *successful* build. You can set alwaysPublish to true, if you want the copy always to happen. Sends an HTTP request to the specified URL. Perform a code analysis using SubMain.CodeItRight. SubMain.CodeItRight is a commerical application that will analyse the code for any standards violations. The tool is available from http://submain.com/products/codeit.right.aspx. Adds a comment to the log. Checks to see if a condition is true before the contained tasks run. A container publisher that only executes the child publishers when the condition (e.g. build status) is met. Sends a management task to a CruiseControl.NET server. Most complex build processes use NAnt Task or MSBuild Task to script the build. However, for simple projects that just need to build a Visual Studio.NET solution, the Visual Studio task <devenv> provides an easier method. Check for duplicates using dupfinder (http://duplicatefinder.codeplex.com/). Publishes results of integrations via email. This implementation supports plain-text, and Html email formats. Rules regarding who receives email are configurable. 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. People tend to prefer to use CCTray rather than email for instant notification these days. Make sure that all of the Merge Publishers, 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. The Executable Task lets you invoke any command line executable. It doesn't offer as much specific integration as (for example) the NAnt Task, but does allow you to hook almost anything up as a build process to CCNet. CCNet will examine the exit code when the executable ends and act accordingly. The FinalBuilder Task allows you to invoke FinalBuilder build projects as part of a CruiseControl.NET integration project. FinalBuilder is a commercial build and release management solution for Windows software developers and SCM professionals, developed and marketed by VSoft Technologies (http://www.finalbuilder.com/finalbuilder.aspx). The ForceBuildPublisher forces a build on a local or remote build server. It uses .NET Remoting to invoke a forced build on the CruiseControl.NET server at the specified URI. The forced build runs asynchronously, i.e. the ForceBuildPublisher does not wait for the forced build to finish. The ForceBuildPublisher is a great way to help Splitting the build. An alternative to the ForceBuildPublisher is the Project Trigger. The main difference is that the ForceBuildPublisher is placed in the configuration for the primary project, while the ProjectTrigger is is placed in the configuration for the dependent project. The ftp task/publisher allows to download or upload files/ folders, for example, uploading a new version of a web page to ftp site of an ISP. Gendarme is a extensible rule-based tool to find problems in .NET applications and libraries. Gendarme inspects programs and libraries that contain code in ECMA CIL format (Mono and .NET) and looks for common problems with the code, problems that compiler do not typically check or have not historically checked. Website: http://mono-project.com/Gendarme Merges external files into the build log. Most build processes interact with external tools that write their output to file (e.g. NUnit, FxCop, or NCover). To make the output of these tools available to CruiseControl.NET to be used in the build process or displayed in the CruiseControl.NET web page or included in CruiseControl.NET emails, these files need to be merged into the CruiseControl.NET integration. You should place your File Merge Tasks in the <publishers /> section of your [Project Configuration Block] before your Xml Log Publisher. This publisher logs all modifications for each build in a file. These modifications can be viewed in the Dashboard with the [modificationHistoryProjectPlugin] plugin enabled. This tasks makes it possible to read back modifications made by the Modification Writer Task. This task writes the detected modifications for the current integration to a file as XML. This enables the modifications to be used by external programs, such as within a NAnt build script. The <msbuild> task is 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. In order to work with the results of MsBuild it is important to use a custom xml logger to format the build results. Runs a NAnt script. Perform a code coverage profile using NCover. NCover is a commerical application that will profile code while unit tests are running. The tool is available from http://www.ncover.com/. CruiseControl.NET only supports NCover 3.x currently. Generate a code coverage report using NCover. NCover is a commerical application that will profile code while unit tests are running. The tool is available from http://www.ncover.com/. CruiseControl.NET only supports NCover 3.x currently. Runs an NDepend analysis. NDepend is a tool that simplifies managing a complex .NET code base. Architects and developers can analyze code structure, specify design rules, plan massive refactoring, do effective code reviews and master evolution by comparing different versions of the code. This application is available from www.ndepend.com. There is both an open source/academic/evaluation version and a professional version. The Null Task is a task that doesn't do anything - it simply returns successfully. This is useful for projects that simply monitor the source control system for changes but don't need to do anything. This task enables you to instruct CCNet to run the unit tests contained within a collection of assemblies. The results of the unit tests will be automatically included in the CCNet build results. This can be useful if you have some unit tests that you want to run as part of the integration process, but you don't need as part of your developer build process. For example, if you have a set of integration tests that you want to run in a separate build process, it is easy to set up a project to use this task. If you are using the Visual Studio Task and you want to run unit tests then you probably want to use this task. Alternatively you can run NUnit using post-build tasks in your Visual Studio project properties. We recommend not using this task, and using your builder to run your tests if possible. This way if the tests fail and you don't know why, it is a lot easier to try and replicate the problem on another machine. When using this task,do NOT merge an xml file from bin folder of your app with the merge task, or the results will be save twice in the buildlog file. Generates a ZIP file package containing the specified files. This will generate a "package" of files in a compressed format. The files must be specified, plus an optional manifest can be included. This publisher also allows the generation of a "manifest" to include in the package. A manifest contains additional details on the package, both at a general level and at a file level. Runs a set of child tasks in parallel. Each task will run at the same time as the other tasks. To run a set of tasks in sequential order within this task, use the Sequential Task. Runs a PowerShell script. Executes Rake. This publisher generates an RSS file reporting the latest results for a Project. The RSS feed is available via the Dasboard in the Project Report. There needs to be 1 build done with this publisher for the icon to show up. Runs a set of child tasks in order. This task is primarily designed for scenarios where execution can take more than more path (e.g. Parallel Task). This is normally not required for tasks directly under the prebuild, tasks or publishers element in a project. The publisher can be used to collect and update statistics for each build in a file. Some of the statistics which would be collected are build durations and test count. At the minimal, the publisher can be configured with just an empty <statistics /> element in the publishers section. This would pick up some default statistics for capturing during the build process. Statistics publisher must come after any File Merge tasks in the publishers section, in case you want to collect statistics from merged files. The task will generate a statistics.csv and report.xml file in the artifact directory. A sychronisation context across multiple tasks or projects. Only one task can be in a synchronisation context at any time. This provides a mechanism for locking, either within a project or inbetween projects. The Xml Log Publisher is used to create the log files used by the CruiseControl.NET Web Dashboard, so if you don't define an <xmllogger /> section the Dashboard will not function correctly. You should place the <xmllogger /> in the <publishers /> section, after any File Merge Tasks, in your Project Configuration Block. The executable to use. The application to profile. The arguments to pass to the application. The priority class of the spawned process. The time\-out period in seconds for the entire task. The time\-out period in seconds for the profiler. Whether to disable all output or not. Whether to display verbose output or not. Whether to overwrite any existing files or not. Whether to include sub\-processes. The level to trace at. Perform method level profiling. Only profile methods that have source code. Whether to use sampling for generating approximate results quickly. Whether to include source code in the results. Whether to allow .NET to inline functions. Whether to get the profiler to compensate for its own overhead. Whether to simplify certain complicated stack traces. Whether to avoid trivial functions or not. Whether to try to record SQL and File I/O events. The base directory to use. If omitted this will default to the working directory of the project. A file containing the args for the profiler in an XML specification. The location to write the summary file to \- uses CSV format. The location to write the summary file to \- uses XML format. The location to write the summary file to \- uses HTML format. The location to write the calltree file to \- uses XML format. The location to write the calltree file to \- uses HTML format. The location to write the data file to (requires desktop application to view). The output analysis file. The threshold level. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. Defines the procedure to use for cleaning up the artifact folder. Defines the value for the cleanup procedure. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The directory to copy the files to. This path can be absolute or can be relative to the project's artifact directory. If *useLabelSubDirectory* is true (default) a subdirectory with the current build's label will be created, and the contents of sourceDir will be copied to it. If unspecified, the project's artifact directory will be used as the publish directory. The source directory to copy files from. This path can be absolute or can be relative to the project's working directory. If unspecified, the project's working directory will be used as the source directory. If set to true (the default value), files will be copied to subdirectory under the publishDir which will be named with the label for the current integration. Always copies the files, regardless of the state of the build. Cleans the publishDir if it exists, so that you will always have an exact copy of the sourceDir. Defines a way to clean up published builds. The value used for the cleaning method. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The list of exit codes that indicate success, separated by commas. The request settings. The number of retries to allow. Whether to include the content of the call in the log. The timeout period to allow. Gets or sets the retry delay. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The executable to use. The solution to analyse. The project to analyse. The name of the XSL file to override the default XSL. The name of the CodeIt.Right .crdata file. When specified, CodeItRight.Cmd will use the exclusion list (violations, rules and files) saved using the Visual Studio version of CodeIt.Right. The name of the User Profile that defines active rule set for the analysis. When omitted, the built\-in profile is used. Severity Threshold value to limit the output violation set. When omitted, the the lowest Severity is used \- None. Severity value to fail the build on. When omitted, the the lowest Severity is used \- None. The time\-out period in seconds. If the task does no finish running in this time it will be terminated. The priority class of the spawned process. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The message to add to the log. Defines whether to fail the task or not. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. Gets or sets the task conditions. Gets or sets the tasks to run if conditions evaluates to true. Gets or sets the tasks to run if conditions evaluates to false. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The publishers to run if the conditions are met. A list of conditions of which at least one must be met in order to run the publishers. A condition to meet. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The server to send the commands to. The actions to perform. An action to perform on a CruiseControl.NET server. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The path of the solution file to build. If relative, it is relative to the Project Working Directory. The solution configuration to use (not case sensitive). Number of seconds to wait before assuming that the process has hung and should be killed. The type of build. A specific project in the solution, if you only want to build one project (not case sensitive). The version of Visual Studio. The path to devenv.com. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The executable to use. The input directory to scan. If relative, this will be relative to the project working directory. The file mask to use. The name of the file to focus on. The time-out period in seconds. The threshold is the number of consecutive lines that have to be the same before it is considered a duplicate. The first line of a duplicate must contain at least this many non-white-space characters. To find files that match the filemask in current directory and subdirectories. Whether to shorten filenames. Whether to include the code that has been duplicated. The lines to exclude. The line to exclude. The files to exclude. The name of the file. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The SMTP server that CruiseControl.NET will connect to to send email. The SMTP server port number. The user name to provide to the SMTP server. The password to provide to the SMTP server. The e-mail address that email will be marked as coming from. Whether to use SSL or not for sending the e-mail. The e-mail address to use for replies. A list of xsl files that will be used to fill up the message body, if left blank the list will be taken from ccnet.exe.config or ccservice.exe.config. The XSL file to use. A list of files to attach to the e-mail. If the full path is not specified, then it will be relative to the project working directory. The attachment to send. Whether to send a full report or not. If not, just sends a simple status message with a link to the build report. A set of <NotificationType> elements, specifying build states for which CruiseControl.Net should send an email to the comitters of the build. The notification type. A set of <user> elements that define who to send emails to. Defines a user who will receive e-mails. A set of <group> elements that identify which the notification policy for a set of users. Defines a group of users to receive e-mails. A set of <subject> elements that define the subject of the email, according to the state of the build (broken, fixed, ...) This element allows to set specific subject messages according to the state of the build. When a certain state is not specified, a default will be entered. A set of elements containing rules for creating email adresses based on the modifiers name. The converters will be used when the name of the modifier is not set in the users section. Looks up the email address via LDAP. Matches the username against a regular expression pattern and modifies it according to a specified replacement. Uses the .NET regular expression language. The find attribute contains a regular expression that is matched against the source control userid. The replace attribute contains a replacement expression that is used to modify the address. Example : Appending "@TheCompany.com" to the username A string that will be the first string of the subject. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The path of the program to run. If this is relative, then must be relative to either (a) the base directory, (b) the CCNet Server application, or (c) if the path doesn't contain any directory details then can be available in the system or application's 'path' environment variable. The directory to run the process in. If relative, is a subdirectory of the Project Working Directory. Any command line arguments to pass in. A set of environment variables set for commands that are executed. Number of seconds to wait before assuming that the process has hung and should be killed. If the build process takes longer than this period, it will be killed. Specify this value as zero to disable process timeouts. The list of exit codes that indicate success, separated by commas. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The full path of the FinalBuilder project to run. Specify 'true' to enable the "banner" at the top of the FinalBuilder console output. One or more FBVariable elements to pass to FinalBuilder. The variable to pass. The name of the variable. The value for the variable. Disable output to the FinalBuilder project log file. Log to a temporary log file which is deleted when the project closes. Overrides DontWriteToLog. The number of seconds to wait before assuming that the FinalBuilder project has hung and should be killed. Use this element to explicitly specify a version of FinalBuilder to run (for instance, you could force a FinalBuilder 4 project to run in FinalBuilder 5.) The absolute path to FBCMD.EXE. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The CCNet project to force build. The URI for the local or remote server managing the project to build. The default value is the default URI for the local build server. The condition determining whether or not the remoting call should be made. The default value is "Success" indicating that the specified build will be forced if the current build was successful Identification of a ForceBuildPublisher. This value is passed to the CCNetRequestSource attribute of the forced project's build. The security credentials to pass through to the remote server. The parameters to pass to the remote project. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The name of the server to connect to. The username to log in with. The password to use. Whether to use active connection mode or not. The action to perform. The path to the folder to use on the FTP server. The to the folder to use on the local machine. Whether to perform a recursive copy or not. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The location of the Gendarme executable. The directory to run Gendarme in. Specify the configuration file. Specify the set of rules to verify. Do not report the known defects that are part of the specified file. Stop reporting after N defects are found. Filter the reported defects to include the specified severity levels. Filter the reported defects to include the specified confidence levels. If true, display minimal output (results) from the runner. Enable debugging output. Specify whenver the build should fail if some defects are found by Gendarme. Specify the assemblies to verify. You can specify multiple filenames, including masks (? and \*). An assembly match. The name expression of the assembly, e.g. "*.dll". Masks (? and *) are allowed. Specify a file that contains the assemblies to verify. You can specify multiple filenames, including masks (? and \*), one by line. The maximum number of seconds that the build may take. If the build process takes longer than this period, it will be killed. Specify this value as zero to disable process timeouts. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The files to merge. The file to merge. The folder to copy the files to. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. When true, the history file will only be updated when the build contains modifications. This setting is mainly for keeping the file small when there are a lot builds without modifications. For example: like CCNet, there is a public website where everybody can force a build. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The filename pattern for the file containing the modifications. CCnet with search in the path for files starting with this filename, and having the same extention. For example when filename is set to modifications.xml, ccnet will search for files like so: modifications\*.xml The directory to search the xml file(s) in. Delete the files after they have been read. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The filename for the file containing the modifications. The directory to write the xml file to. Appends the integration start time to the filename, just before the extention. Making it possible to create a modification file per integration, without overwriting existing ones. Intended to be used with the [Modification Reader Task]. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The location of the MSBuild.exe executable. 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. The name of the build project to run, relative to the workingDirectory. Any extra arguments to pass through to MSBuild. A semicolon-separated list of the targets to run. 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. Only if the assembly contains more than one logger implementation you need to specify the logger class (see MSBuild reference): [LoggerClass,]LoggerAssembly[;LoggerParameters] Number of seconds to wait before assuming that the process has hung and should be killed. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. A list of targets to be called. CruiseControl.NET does not call NAnt once for each target, it uses the NAnt feature of being able to specify multiple targets. The name of the target. The path of the version of nant.exe you want to run. If this is relative, then must be relative to either (a) the base directory, (b) the CCNet Server application, or (c) if the path doesn't contain any directory details then can be available in the system or application's 'path' environment variable The name of the build file to run, relative to the baseDirectory. The directory to run the NAnt process in. If relative, is a subdirectory of the Project Working Directory. Any arguments to pass through to NAnt (e.g to specify build properties). The NAnt logger to use. The NAnt listener to use. Whether to use the -nologo argument when calling NAnt. The maximum number of seconds that the build may take. If the build process takes longer than this period, it will be killed. Specify this value as zero to disable process timeouts. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The program to execute and collect coverage stats from. The project that contains the tests. If relative, this will be relative to baseDir. The parameters to pass to the program. The executable to use. The time-out period in seconds. If the task does no finish running in this time it will be terminated. The base directory to use. All relative parameters will be relative to this parameter. The working directory to use. If relative, this will be relative to baseDir. Whether to publish the output files or not. The location of the NCover log file. If relative, this will be relative to baseDir. The profiler log level. The name of the project (used in the HTML report). The location to write the coverage file to. If relative, this will be relative to baseDir. The coverage metric to use. The attributes to exclude. The assemblies to exclude. The files to exclude. The methods to exclude. The types to exclude. The attributes to include. The assemblies to include. The files to include. The types to include. Whether to turn off autoexclusion or not. The module to process. The symbol search policy to use. The location to write the trend file to. A custom build id to attach. The location to read the settings from. If relative, this will be relative to baseDir. Temporarily enable NCover. The amount of time that NCover will wait for the application to start up. Whether to cover IIS or not. The timeout period for covering a service. The windows service to cover. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The executable to use. The time-out period in seconds. If the task does no finish running in this time it will be terminated. The base directory to use. All relative parameters will be relative to this parameter. The working directory for the executable. If relative, this will be relative to baseDir. The location to read the coverage date from. If relative, this will be relative to baseDir. Should the coverage filters be cleared. The filters to apply. A filter for a coverage report. The minimum coverage thresholds. A threshold for a coverage report. Whether to use minimum coverage or not. The type of report filtering to use. The satisfactory coverage thresholds. A threshold for a coverage report. The maximum number of items to report. The file to append the trend to. The file to import the trend from. A custom build id to attach. The elements to hide. The directory to output the reports to. If relative, this will be relative to baseDir. The type of report to generate. The type of report. The project name to use. The sort order to use. The amount of uncovered items to cover. The merge mode to use. The file to store the merged data in. If relative, this will be relative to baseDir. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The NDepend project file. This is generated from VisualNDepend. The executable to use. Whether to emit the XML report data or not. The output directory to use. The input directories to use. The input directory. Whether to hide any output or not. The location of a custom report XSL-T. The time-out period in seconds. The base directory to use. If omitted this will default to the working directory of the project. Whether to publish the output files or not. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. Defines whether to fail the task or not. List of the paths to the assemblies containing the NUnit tests to be run. The assembly to test. Path of *nunit-console.exe* application. The file that NUnit will write the test results to. The number of seconds that the nunit process will run before timing out. List of the test categories to be excluded from the NUnit run. The tests need to have the CategoryAttribute set. The category to exclude. List of the test categories to be included in the NUnit run. The tests need to have the CategoryAttribute set. The category to exclude. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The name of the package file. The level of compression to use. The valid range is from zero to nine, zero is no compression and nine is maximum compression. Whether the package should always be generated or not. Should the file structure be flattened or not. The manifest generator to be used. The list of files and folders to include in the package. The location to output the package to. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. A set of environment variables set for commands that are executed. Includes the file in the package. Includes the folder and its contents into the package. The name and path of the file to store into the package The name of the file that is to be saved. The name of the folder in the package that the file will be saved under The name of the folder to store into the package The filename filter to apply The name of the folder in the package that the file will be saved under Recursively save files Flatten the hierachy The tasks to run in parallel. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The PowerShell script to run. The directory that the PowerShell scripts are stored in. Any arguments to pass into the script. Any environment variables to pass into the script. The maximum number of seconds the build can take. If the build process takes longer than this period, it will be killed. Specify this value as zero to disable process timeouts. The PowerShell executable. The exit codes that mark the script as being successful. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. Any arguments to pass through to Rake (e.g to specify build properties). The directory to run the Rake process in. If relative, is a subdirectory of the Project Working Directory. Number of seconds to wait before assuming that the process has hung and should be killed. Do not log messages to standard output. The path of the version of Rake you want to run. If this is relative, then must be relative to either (a) the base directory, (b) the CCNet Server application, or (c) if the path doesn't contain any directory details then can be available in the system or application's 'path' environment variable. The name of the Rakefile to run, relative to the baseDirectory. Like quiet but also suppresses the 'in directory' announcement. A list of targets to be called. CruiseControl.NET does not call Rake once for each target, it uses the Rake feature of being able to specify multiple targets. The name of the target. Turns on invoke/execute tracing and enables full backtrace. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The number of items to be displayed. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The tasks to run in sequence. Should the tasks continue to run, even if there is a failure? The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The list of statistics to be included in the build. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The tasks to run within the synchronisation context. These tasks will be run in the order they are defined. Should the tasks continue to run, even if there is a failure? The name of the synchronisation context. This is only needed if multiple synchronisation contexts are desired. The timeout period (in seconds). The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. The directory to save log files to. If relative, then relative to the Project Artifact Directory. The dynamic values to use for the task. Description used for the visualisation of the buildstage, if left empty the process name will be shown. Checks that all the child condition pass. Checks if the current build condition matches a value. Checks if two values are the same. This is typically used with dynamic values. Checks if a file exists. Checks if a folder exists. Checks if the last build was at least a certain time period ago. Checks if the status of the last build matches a value. Checks that at least one child condition matches. Checks if the current status matches a status. Checks if a URL returns a specified header. Checks if a URL can be pinged. The conditions to check. A description of the condition. The build condition to match. A description of the condition. The first value to evaluate. The second value to evaluate. The type of evaluation. Whether to ignore any case differences or not. A description of the condition. The file to check for. A description of the condition. The folder to check for. A description of the condition. The time period to use. A description of the condition. The status to match. A description of the condition. The conditions to check. A description of the condition. The status to match. A description of the condition. The URL to ping. The key of the header to check. The expected value for the header. A description of the condition. The URL to ping. A description of the condition. The directory to save the state file to. The folder to store the XML in. The folder to store snapshots. The folder to store the JSON in. The folder to store snapshots. 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. The filter will exclude modifications that occur between the start time and the end time on the days specified. If the start time is greater than the end time then the filtered time will span across midnight. For example, if the start time is 23:00 and the end time is 3:00 then builds will be suppressed from 23:00-23:59 and 0:00-3:00 on the days specified. Like all triggers, the scheduleTrigger must be enclosed within a triggers element in the appropriate [Project Configuration Block]. 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. The items to watch for modifications are specified with Source Control Blocks. Like all triggers, the intervalTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. 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. It is possible to change the logical operator applied to assessing the build conditions. If the Multiple Trigger's operator property is set to "And" then if any trigger says that a build should not happen, then the build will not happen. This is particularly useful when using multiple Filter Triggers. Like all triggers, the multiTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. Trigger to add build parameters to an integration request. Like all triggers, the parameterTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. The configuration of the nested trigger is not the same as when using that trigger outside a filter trigger. When using the <parameterTrigger> element, the inner trigger must be specified with the <trigger> element. You could not use the <intervalTrigger> trigger element in this example. 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. The Project Trigger works by using .NET remoting to poll the status of the dependent project. Whenever it detects that the dependent project has completed a build, the Project Trigger will fire. The Project Trigger can be configured to fire when the dependent project build succeeded, failed or threw an exception. In order to avoid hammering the remote project through polling, the Project Trigger is composed of an Interval Trigger that will set a polling interval to 5 seconds. This inner trigger can be adjusted through changing the configuration. Like all triggers, the projectTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. 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. The items to watch for modifications are specified with Source Control Blocks. Like all triggers, the scheduleTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. 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. Like all triggers, the urlTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block. The inner trigger to filter. The condition that will be returned if a build is requested during the filter window. The default value is *NoBuild*indicating that no build will be performed The start of the filter window. Builds will not occur after this time and before the end time. The end of the filter window. Builds will not occur before this time and after the start time. The week days on which the filter should be applied (eg. Monday, Tuesday). By default, all days of the week are set. The filter will have no effect on other days. The day of the week. The condition that should be used to launch the integration. By default, this value is *IfModificationExists*, meaning that an integration will only be triggered if modifications have been detected. Set this attribute to *ForceBuild* in order to ensure that a build should be launched regardless of whether new modifications are detected. The name of the trigger. This name is passed to external tools as a means to identify the trigger that requested the build. The number of seconds after an integration cycle completes before triggering the next integration cycle. The delay (in seconds) from CCNet startup to the first check for modifications. The logical operator to apply to the results of the nested triggers (And or Or). The nested triggers. The inner trigger to filter. The parameters to pass onto the inner trigger. The name of the dependent project to trigger a build from. The URI for the CCNet server containing the dependent project. The status of the dependent project that will be used to trigger the build. For example, if this value is set to Success then a build will be triggered when the dependent project completes a successful build. The trigger used to modulate the polling interval for the ProjectTrigger. By default, this is set to a ForceBuild IntervalTrigger that will cause the trigger to check the status of the dependent project every 5 seconds. Whether to trigger on the first time or not. The condition that should be used to launch the integration. By default, this value is *IfModificationExists*, meaning that an integration will only be triggered if modifications have been detected. Set this attribute to *ForceBuild* in order to ensure that a build should be launched regardless of whether new modifications are detected. The week days on which the build should be run (eg. Monday, Tuesday). By default, all days of the week are set. The day of the week. The time of day that the build should run at. The time should be specified in a locale-specific format (ie. H:mm am/pm is acceptable for US locales.) Adds a random amount of minutes between 0 and set value to the time. This is mainly meant for spreading the load of actions to a central server. Value must be between 0 and 59. The name of the trigger. This name is passed to external tools as a means to identify the trigger that requested the build. The condition that should be used to launch the integration. By default, this value is *IfModificationExists*, meaning that an integration will only be triggered if modifications have been detected. Set this attribute to *ForceBuild* in order to ensure that a build should be launched regardless of whether new modifications are detected. The url to poll for changes. The name of the trigger. This name is passed to external tools as a means to identify the trigger that requested the build. The number of seconds after an integration cycle completes before triggering the next integration cycle. The delay (in seconds) from CCNet startup to the first check for modifications. The type of the file to merge. The time unit to use. The variable to pass. The name of the environment variable. The value of the environment variable. The value to pass. The value to pass. The name of the value. The name of the domain to use. The name of the user to impersonate. The password of the user. The name of the file to import. This will replace the value of a property with the value from a parameter. If the user does not enter a parameter value, then the default will be used (when set). This dynamic value does not perform any formatting, it just directly puts the value into the property. This will replace any number of parameters into a format string. The format string can also include formats for each parameter. The name of the property to set. This must be the same name as what is in the task/publisher/trigger configuration. The name of the parameter to use. This must be the same name as what is in the parameters configuration. The default value to use if nothing is set in the parameters. A statistic that extracts the first item that matches the specifed XML XPath. A generic statistic. The name of the property to set. The parameters to use. The default value to use if nothing is set in the parameters. The XML XPath to locate the value of this statistic. The name of the statistic. Should a graph be generated for this statistic? Should this statistic be collected and published? The XML XPath to locate the value of this statistic. The name of the statistic. Should a graph be generated for this statistic? Should this statistic be collected and published? The domain to query for the LDAP service. The field in the LDAP service to use for mapping the source control userid. Username for logging into the LDAP service. The password to use for connecting to the LDAP service. A regular expression to match against the username and identify parts to be replaced. A string to replace the matched pattern in the username. The value of the subject line, the text to be used for the subject. This may contain variables, see below. A build result state, see below for the possible values. The name of the group, which corresponds to the "group" values used in the <user> elements. A list of notification types, determining when to send email to this group. The type of notification. The user name of a user. This should match the user name in Source Control. The Internet-style email address of the user (e.g., "joe@example.com"). The group that the user is in. This needs to match the name of one of the <group> elements. The name of the header. The value of the header. The project to run the command on. The type of command. The coverage metric. The minimum coverage value. The type of item. The matching pattern to use. The pattern to use for matching elements. The type of item. Whether this is a regex or not. Whether to include or exclude items. The method to use. The HTTP headers to send. A header for an HTTP request. The body of the request to send. A file to send in the request. The URL to make the request to. The timeout period before cancelling the request. The read/write timeout period. The credentials to use in the request. The user name to use. The password to use. The domain to use. Whether to use the default credentials or not. Defines the permissions for a role (a group of users). Defines the permissions for a user. The default right to use. The right to send messages. The right for force or abort builds. The right to stop and start projects. The right to change the configuration of projects. The right to view security. The right to modify security. The right to view a project. The right to view configuration and logs. The users in this role. The name of a user. The default right to use. The right to send messages. The right for force or abort builds. The right to stop and start projects. The right to change the configuration of projects. The right to view security. The right to modify security. The right to view a project. The right to view configuration and logs. The name of the role. The identifier of the referenced permission. The user name. The identifier of the referenced permission. The name of the user.