CruiseControl.Net patches


Hacking CruiseControl.Net to work better for my specific circumstances (lots of projects that depend on lots of projects) has resulted in the following patches to revision 3607 of ccnet which I'm just about to submit to the developers.

These patches are 'supporting patches' to the main ProjectTrigger and integrator changes, I thought I'd start with the simple ones... None of these patches should change existing functionality, all require new, optional, properties to be specified to activate the new code. All patches include updated and or new tests.

1) IntervalTrigger - Added initialIntervalSeconds.

initialIntervalSeconds is a new property that controls when the trigger fires the first time. The idea being that you might want to have a trigger that fires every 'X' seconds but you dont want to have to wait a full 'X' seconds for it to fire when the server first starts up. If initialIntervalSeconds is set then the trigger will first fire after this number of seconds and will then switch to firing every intervalSeconds as normal.

I find this useful when running ccnet on machines which aren't dedicated build machines (i.e. machines that don't have ccnet running all the time) for projects that I don't want to run very often but, when I start ccnet, I want them to be checked...


2) IFileSystem changes - Added some more functionality to support the tests for the changes in patches 3 and 4.

Added CreateDirectory() and DeleteDirectory().


3) CVS source control - allow non existent working directory to be created.

Changes to DoesCvsDirectoryExist() and NewProcessInfoWithArgs() to allow for creation of working directory if required for checkout or update only.


4) FileSourceControl - allow working directory to be specified and added a property to force deletion of remove files during GetSources.

I've added a working directory property so that you can have a FileSourceControl source control block that checks files out to a sub directory of the project's working directory. This is useful if you are accumulating files from multiple source control blocks into a directory tree and want to place some of the files in subdirectories.

The second change forces the working directory to be removed before an update occurs. This is a brute force method of removing files which no longer exists in the repository from the working copy.


5) Visual C++ version 6 "MsDev" build task.

Added a new build task that works with Visual studio 6.


6) Allow you to specify which version of Visual Studio is used if mutliple versions are installed without having to know the executable path. Although you can currently select the version of visual studio that is used you need to do it by providing the full path to the executable this patch allows you to simply say "I'd like Vs2003 please" and then used the registry query code to work out where it is installed. This is enabled by specifying a Version property with a value of one of the following: "9.0", "8.0", "7.1", "7.0", "VS2008", VS2005", "VS2003" or "VS2002". I considered, and rejected, having the DevenvTask read the solution file and work out the appropriate version as unecessarilly complex.

This removes the need to embed potentially machine specific information in a config file just to select which version of VS you want to use; though, unfortunately it doesn't help me on Vista x64 as the InstallDir value isnt present in the registry :(


With any luck these will be approved and incorporated into the subversion ccnet repository soon, but, if they're not you can get them from here.

I'm currently working on tidying up the ProjectTrigger changes that are mentioned here and these will be released later. The Sleep() changes to the ProjectIntegrator were more complex than expected (mainly due to the design of the integration thread), although my hacked version works for me it's not good for prime-time so I'm working on a better fix.


I've run into that InstallDir problem under Vista x64 before. On my machine I found INstallDir for
7.1 & 8.0 at:


Ah, of course, thanks for that. I expect it's fixable then, with a bit of jiggery pokery; CC.Net is most probably running as an x64 process and so doesn't get to see the WOW64 node by default...

C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\

should be

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\

Note that is not installed in that directory anymore.

C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\

should be

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\

Note that is not installed in that directory anymore.

Any chance on getting a visual basic task for visual studio 6? I have a COM+ project "trapped" in VB6... :(

Matt, your best bet is to ask on the CC.Net mailing list. I only hacked around with it because I needed it to do things for my builds...

Leave a comment