Figuring this out took me much longer than it should. The following line in a batch file will execute a command for each file in a directory:

for %%I in (C:\*.*) do echo %%~nxI

I had to overcome two obstacles to make this work:

• When including the command in a batch file the % characters must be duplicated in comparison to the syntax for executing the command directly from the command line.
• The ~nx prefix to the variable name causes only the filename with extension to be used instead of the complete path.

Once you start putting CruiseControl.NET to production use you'll sooner or later encounter the need for custom build tasks. There's only a limited set of them in the package and Executable Task can only do so much. Unfortunately there is not much information available on development of custom tasks. Your best sources will be:

• Online documentation contains an article on the subject describing the first steps to get you going. It should be your first stop.
• There's a high level architectural overview of a simple task available at Josh's Blog.
• Lutz Roeder's Reflector for .NET will be your best friend. The source of the tasks in ThoughtWorks.CruiseControl.Core will soon become your best resource.

Apart from that I feel obliged to mention a few of the most important points I've come across during the development of a few custom tasks:

• ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor is a nice little wrapper around System.Diagnostics.Process class you'll end up using quite a lot.
• You can add your own information to the build log by calling AddTaskResult on the IIntegrationResult instance passed to your ITask.Run method. There are two overloads available: one accepting a System.String and another one accepting ITaskResult to which you can pass a new FileTaskResult instance to quickly include a complete file.
• If you're doing any checkins to your source control system as a part of the build you should call the MarkStartTime method of your IIntegrationResult instance afterwards to prevent triggering another build of the same project by setting the last build start time after the last checkin time.
• Make sure you use a unique ReflectorType name for your task. The service will just silently fail to start in case of a duplicate value.

This information should make your first attempts at making your own custom task a little easier.

The 1.3.0.2918 build of CruiseControl.NET has an error in msbuild.xsl file which causes an XslLoadException to be thrown when trying to view the MSBuild output in the web dashboard. One of the users was nice enough to describe the changes to the file necessary to fix the problem. Unfortunately even the latest version of the file on the CruiseControl.NET Live site doesn't include the changes therefore I'm attaching the file to this post as convenience.

Although a MSI file can bi installed by double clicking on it in Explorer or by selecting install from the context menu, you might want to start from command line to include it in a script. This can be done by using the msiexec.exe utility. Although it's parameters are well documented I had to do some searching to find a way for setting a different installation directory than the default one in case the configuration forms are skipped with the /qb option. It can be done by setting the INSTALLDIR property to the desired value.

As a future reference the following command line triggers the setup package to install into the specified directory without opening any additional configuration windows:

msiexec /i MyMSI.msi /qb INSTALLDIR="C:\Program Files\My Install Dir"