Monitoring multiple VSS projects in CruiseControl.NET

One of the most useful techniques I have found in working with CCNet and VSS is the ability to monitor multiple VSS project folders to trigger a build. Many times, you will find your solution structured such that monitoring a top level folder may not be the right level for triggering a build. If this is your problem, then <sourcecontrol type=”multi”> might just be your solution.

Here is a simple example of how you can monitor multiple projects within VSS to trigger a Visual Studio build to happen:

<project name="MySoftware">
        <workingDirectory>C:\Dev\ProjectXYZ\4.0\GUI</workingDirectory>
        <modificationDelaySeconds>10</modificationDelaySeconds>
        <sourcecontrol type="multi">
            <sourceControls>
                <vss>
                    <executable>C:\Program Files\Microsoft Visual SourceSafe\SS.EXE</executable>
                    <project>$/Dev/ProjectXYZ/4.0/GUI</project>
                    <username>BuildUser</username>
                    <password>BuildPassword</password>
                    <ssdir>\\server\share\vssdir\</ssdir>
                    <workingDirectory>c:\dev\projectxyz\4.0\GUI</workingDirectory>
                    <cleanCopy>true</cleanCopy>
                </vss>
                <vss>
                    <executable>C:\Program Files\Microsoft Visual SourceSafe\SS.EXE</executable>
                    <project>$/Dev/Shared/ComponentABC/5.1</project>
                    <username>BuildUser</username>
                    <password>BuildPassword</password>
                    <ssdir>\\server\share\vssdir\</ssdir>
                    <workingDirectory>c:\dev\shared\componentabc\5.1</workingDirectory>
                    <cleanCopy>true</cleanCopy>
                </vss>
            </sourceControls>
        </sourcecontrol>
        <tasks>
            <devenv>
                <solutionfile>MySoftwareSolution.sln</solutionfile>
                <configuration>Release</configuration>
                <executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe</executable>
            </devenv>
        </tasks>
    </project>

In this example, we are watching for code changed in either ProjectXYZ or shared ComponentABC. Monitoring recursively for any changes below $/Dev may cast much too large of a net to effectively limit the number of CI builds triggered.

Another useful application mentioned on the CruiseControl.NET documentation for this feature is that you can monitor different types of repositories, including a filesystem. So if you have some dependencies that you want to rebuild with that get posted to a file server, this can trigger a build based on changes there as well.

VSS and CruiseControl.NET

Recently, a respected member of the .NET community asked for some “gotchas” when using SourceSafe with CruiseControl.NET. At first, I was thinking, “There really aren’t any. It is working fine for us” however when thinking back on the setup of the current infrastructure I recall there was some tweaking necessary to get things rolling.

DISCLAIMER: I would like to preface any content of this article by saying that I am by no means a VSS fan. It is free, it is just good enough, and it is already in place. I already know what tool I want to switch to when the time is right, but for today I work in a VSS shop.

So, if you are going to setup CCNet with SourceSafe, here are some things to keep in mind. With respect to things to stay away from, I experienced some issues when I tried to monitor a large number of projects. You also may experience VSS timeouts if the project folder you point to has too many subfolders/files. In some cases, the VSS history command to see if anything had changed since the last build took longer than the preset timeout (I believe it is 30 seconds)!!! So it would help to be selective in the points you monitor within VSS. If you keep your solutions/projects to smaller, more manageable sets of code you’ll probably be more successful.

One thing you could try is to time the history commands from a command line. When using VSS, CCNet essentially issues a command like the following:

SS.EXE history $/Devl/Products/XYZ/Common/2.0/Batch -R -Vd12/5/2007;5:01a~12/4/2007;1:11p -YBuildUser, -I-Y

By executing this manually you can get a feel for how long it will take to execute the command. The CCNet logs will show if you experienced a timeout:

2007-12-05 05:04:20,165 [Accounting Batch 2.0:WARN] Process timed out: C:\Program Files\Microsoft Visual SourceSafe\SS.EXE history $/Devl/Products/XYZ/Common/2.0/Batch -R -Vd12/5/2007;5:01a~12/4/2007;1:11p -YBuildUser, -I-Y.  Process id: 3928.  This process will now be killed.
2007-12-05 05:04:22,994 [Accounting Batch 2.0:WARN] The process has been killed: 3928
2007-12-05 05:04:23,040 [Accounting Batch 2.0:ERROR] Exception: Source control operation has timed out.

Despite some pain getting the right level of monitoring, it is now a useful tool. I would definitely encourage use of the CCTray app for all developers. This seems to be the easiest way to communicate a breakage. You can also use the web dashboard to show the history of what has happened: