CruiseControl.NET's Web Application Issue

While I didn't officially make a New Year's resolution, I do want to use more of the developer tools that Agile methodologies have made popular.

For instance, I'm pretty set in my ways, so this whole test-driven development thing is going to be a real challenge to me. But, I see that resistance is futile, so I'll join the Borg now.

One thing that I'm exploring is the role that Continuous Integration provides while working on a project. What this is, as best as I can describe it, is a way of automatically building the project's source code, running tests, and reporting on the results. This way, at any time, you can always get the latest build, and assuming that you have unit tests, can be sure that the latest build passes all tests.

One tool to facilitate Continuous Integration for the .NET platform is CruiseControl.NET. I was first introduced to CC.NET by an article in CoDe Magazine last year written by Dr. Neill in his screenplay-like writing style.

Well, I have successfully configured CC.NET to retrieve the latest source code from Visual Source Safe 2005, build it using MSBuild, and maintain stats through a web application that it provides. A step in the right direction, to say the least.

The CCNET web application includes a link to CCTray (a Win32 client for CC.NET), which points to a path within the CCNET virtual directory structure:

http://servername/ccnet/CCTray/CruiseControl.NET-CCTray-1.0-Setup.exe

When I first clicked on this link, I got a 404 Page Not Found error. "Hmm, that's weird. Why would they not include the setup file that the link pointed to?" I thought to myself.

But, while exploring the server, I noticed that the file was indeed there. Why would IIS return a 404 then?

Well, as it turned out, the CCTray virtual directory was set for "Scripts and Executables". This means that when I requested the EXE, that IIS tried to run the EXE on the server (think CGI) instead of sending me the file's bits through the response stream. In fact, the whole ccnet web application was configured for "Scripts and Executables" out of the box!

The obvious fix was to change the web application permission to just "Scripts". This allows ASP (and ASP.NET) pages to run without trying to execute binaries on the server if and when they are requested.