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 Publisher]s, 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.

<email from="buildmaster@mycompany.com" mailhost="smtp.mycompany.com" mailport="25" includeDetails="TRUE"
           mailhostUsername="smtpuser" mailhostPassword="smtppassword" useSSL="FALSE">

    <users>
        <user name="BuildGuru" group="buildmaster" address="buildguru@mycompany.com"/>
        <user name="JoeDeveloper" group="developers" address="joedeveloper@thoughtworks.com"/>
    </users>

    <groups>
        <group name="developers">
           <notifications>
	       <notificationType>Failed</notificationType>
	       <notificationType>Fixed</notificationType>
	   </notifications>
        </group>
        <group name="buildmaster" >
           <notifications>
	       <notificationType>Always</notificationType>
           </notifications>
        </group>
    </groups>

    <converters>
       <regexConverter find="$" replace="@TheCompany.com" />
    </converters>

    <modifierNotificationTypes>
       <NotificationType>Failed</NotificationType>
       <NotificationType>Fixed</NotificationType>
    </modifierNotificationTypes>

    <subjectSettings>
       <subject buildResult="StillBroken" value="Build is still broken for {CCNetProject}" />
    </subjectSettings>

    <xslFiles>
       <file>xsl\header.xsl</file>
       <file>xsl\compile.xsl</file>
       <file>xsl\unittests.xsl</file>
       <file>xsl\modifications.xsl</file>
    </xslFiles>

    <attachments>
        <file>C:\Data\AFile.txt</file>
        <file>Relative.txt</file>
    </attachments>
</email>

Configuration Elements:

The authentication elements, mailhostUsername and mailhostPassword, are available starting in CCNet 1.2.

When includedDetails = True, the message body will contain more information. This detailed information is constructed from xsl transformations on the build log. If the xslFiles section is filled these files will be used, if not defined the xls files are defined in the ccnet.exe.config in the xslFiles section. (see also : Server Application Config File). when adjusting one of these, restart the console/service. The benefits of defining the xsl files in the email publisher : ° the xsl files are automatically the same for the console as for the service (no more keeping these 2 in sync) ° it is possible to give projects different xsl transformations

The groups node may be empty, but the group section must exist.

For sending mail via gmail : mailhost="smtp.gmail.com" mailport="587" mailhostUsername="xxx.yyy@gmail.com" mailhostPassword="yourpassword" useSSL="TRUE"

User Configuration Element:

Users do not need to belong to a group. If they are not in a group then they may still receive emails when they have committed changes that are part of the current build, depending on the setting of "modifierNotificationTypes" and the state of the build.

See the section on the <converters> setting for manipulations that can be done to transform a user name to an address if the address is not specified.

It is essential that the value of the name attribute matches the name for the user in the sourcecontrol system. This is the only way that CruiseControl.Net can reconcile the user that committed a change with the address to send the email to.

Group Configuration Element:

The ability to configure notifications for successful builds is available starting in CCNet 1.3.

Converters Configuration Element:

The <converters> configuration specifies rules for transforming user names (from <user> elements) to email addresses in cases where the <user> element does not specify an address. The converters are ignored when the <user> element specifies an address.

The converter rules are applied in the order in which they are specified. The first rule transforms a source control userid into a result. Each subsequent rule transforms the result of the previous rule into a new result. The last rule transforms the previous result into an email address. In the simplest case - a single rule - the rule transforms a source control userid into an email address.

Regular Expression Converter Element:

The <regexConverter> element matches the username against a regular expression pattern and modifies it according to a specified replacement. The regular expression language is that of Microsoft's .NET System.Text.RegularExpressions.Regex class.

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

This will transform the source control userid "js" into "js@TheCompany.com"

<converters>
    <regexConverter find="$" replace="@TheCompany.com" />
</converters>

Ldap Converter Element

The <ldapConverter> element looks up the email address via LDAP. (available from 1.4.1.3843)

Example

This will search the LDAP for source control userid "js" , using default settings.

<converters>
    <ldapConverter domainName="TheCompany" />
</converters>

This will search the LDAP for source control userid "js" , specifying a user for querying the LDAP.

<converters>
    <ldapConverter domainName="TheCompany" ldapLogOnUser="LdapQuery"  ldapLogOnPassword="LdapQueryPW" />
</converters>

ModifierNotificationTypes Configuration Element:

The <modifierNotificationTypes> configuration specifies the build states for which CruiseControl.Net should send email to the users who contributed changes.

The values of NotificationType are:

Users who contribute modifications to a failed build are "sticky". As long as the builds continue to fail, CruiseControl.Net remembers each user who contributed a change to any of the builds. When a build finally succeeds, this list of "failure modifiers" is cleared.

SubjectSettings Configuration Element

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.

Buildresult states : 

It is also possible to use variables in this section, these variables are the integration properties :

This makes it possible to set up subjects like following :

<subjectSettings>
   <subject buildResult="StillBroken" value="Build is still broken for ${CCNetProject}, please check again  />
</subjectSettings>

or

<subjectSettings>
   <subject buildResult="StillBroken" value="Build is still broken for ${CCNetProject}, the fix failed. />
   <subject buildResult="Broken" value="{CCNetProject} broke at ${CCNetBuildDate} ${CCNetBuildTime } , last checkin(s) by ${CCNetFailureUsers}  />
   <subject buildResult="Exception" value="Serious problem for ${CCNetProject}, it is now in Exception! Check status of network / sourcecontrol />
</subjectSettings>

Troubleshooting

You can find further troubleshooting hints on the System.Web.Mail faq site