Google Summer Of Code 2013

Read more about the Google Summer of Code here:

Background information about CCNet.

CruiseControl.NET is an Open Source Automated Continuous Integration server, implemented using the .NET Framework.
It's a project with a long history (it started somewhere around 2001). From the first commit in GIT you can see that it is a CVS to SVN conversion in 2003.
This means that a lot of different people have contributed to it and that the code base has grown organically.
You can find statistics on Ohloh

More general information can be found here : About
Developer information can be found here :

Breaking changes are not a real problem, but should be kept at a minimum as this requires users to update their configs / plugins.
If a new feature gives great benefit, a breaking change is not a problem, but a breaking change for getting text bold in the UI is not acceptable.

Project list

New Web Dashboard

Brief explanation: create a new WEB UI for CCNet adding CRUD actions on the build projects.

Expected results:
Create a modern Web UI that also allows for project maintenance (adding, editing of build projects) while remaining the
current functionality :
  • Overview of current build activity
  • Viewing build artifacts (build results, nant output, nunit output, ...)
  • security aspects (right to view a project, to force a build, to edit configuration, ...)
  • plugin architecture must be kept (preferably the current one, if required another one is an option)
  • the concept of packages
  • the power of the pre-processor must be kept (templates)
  • the dashboard visualizes several build servers.

you can see our buildserver here

We know that this is a lot of work, but if the ground work is done, we're also very happy.
Information about the technologies used must be provided.

Knowledge Prerequisite:
Good knowledge of C# and modern web development. Knowledge what a build server does is a plus.

Ruben Willems or Daniel Nauck

Mono compatibility

Brief explanation:
Make CCNet work on MONO out of the box.

Expected results:
Alter the code and possibly the build so that MONO compatibility is ensured
This could mean that projects have to be split (not a problem).

Knowledge Prerequisite:
Good knowledge of C# and MONO.

Daniel Nauck or Ruben Willems

Memory friendly XSLT parsing

Brief explanation:
Goal is to reduce/eliminate out-of-memory exceptions on xslt transforms.
Lesser CPU usage is also a possible gain here.

Expected results:
Transforming the large build artifacts with xslt should put lesser strain on the build server.
This problem occurs more frequently when there are a lot of builds at the same time.
For example : compile CCNet with msbuild on it's most verbose setting, and merge FXCop, Gendarme, NCover and NDepend results into it.
This gives a rather large result file, and every output in the dashboard / mailing loads this big result set.
Other ideas on fixing this problem are also welcome.
For the moment there is already the possibility on pre-processing the in-between xml files, making them smaller by eliminating unwanted information.
But this is not out-of-the-box as we can not predict what is unwanted information for each user.
Ditching xml is not an option since most tools output in XML.

Knowledge Prerequisite:
Knowledge of C# and XML/XSLT.

Daniel Nauck or Ruben Willems