I’ve never seen a more timely blog entry.  Like that episode of Family Guy where Joe is down about being handicapped, and a commercial comes on for the special peoples games, and then the news says “Coming up, our expose on conveniently timed television shows, but first, watch out for that skateboard Peter” and then Peter trips on a skateboard….

So…rambling…oh yeah.  Earlier I was discussing my build environment, and I was a little down about NDepend not being a default integration item, and rather than putting in the work I used an <externalLink> in ccnet.config to link to the NDepend output.

So…reading today's Daily Grind I see this fantastic and perfectly timed post on Robin’s blog that does…you know…*exactly* what I wanted.  Go there to get the full scoop and the .xsl files for the transformation, but it works like a charm.  My only modification was to remove some of the css formating in the different xsl files because they were mucking up the design of the webdashboard.  The offending lines are right at the top of the css definition in each of the files though, so they’re not hard to hack out:

#NDepend-report { font-family: Trebuchet MS; font-size: 10pt; }
TD { font-family: Trebuchet MS; font-size: 10pt; }

And one of the files at least set an explicit Body style, so I hacked that out too.  With that handled the NDepend reports are right where they should be, with the other stuff. 

The other modification I made is really an addition to what Robin has.  In the dashboard.config file, in the <buildReportBuildPlugin> section, if you add another <xslFile> for the ndependsummary-ccnet.xsl to where the header.xsl and compile.xsl and all those are you get the summary view of the NDepend report right on the same build summary page as the other summary information.  Useful for me, maybe not for you, but the option is there.

So again, big ups to Robin  for his well timed article.  Thanks!

On to the poorly documented goodness…a few notes on CruiseControl.NET 0.9.2 that I’ve run across:

Publishers and Tasks…the docs make it seem like you can put all the publishers in the <tasks> block…untrue.  You have to use the <publishers> block.

The email publisher documentation is wrong.  It states that the notification attribute can have “two possible notification values” but lists 3.  “always”, “change”, and “failed”.  Well…”failed” doesn’t work and throws an error that goes a little something like this:

Exception: Unable to instantiate CruiseControl projects from configuration document. Configuration document is likely missing Xml nodes required for properly populating CruiseControl configuration.Unable to assign value "failed" to member "ThoughtWorks.CruiseControl.Core.Publishers.EmailGroup.NotificationString".

“Failed” is bad mmkay?  “Fail” also doesn’t work in case you want to try it.  That’s a bummer because I wanted to set up an explicit fail notification.  I can still do so in NAnt, but I wanted all that to be in the same spot in the ccnet side of it.  Seems like this might be a case of the left hand not knowing what the right is doing.

Another thing, if you have an error in your ccnet.config file, it will not stop ccservice from running.  And it will keep going doing what it’s been doing.  What I think is happening, and I have not in any way verified this, but it looks like it keeps some sort of “last known good” config in memory and runs off of that if there’s a problem.  Because the changes I was making to merge the NDepend xml files were not taking effect at all, and the “failed” error was happening, but the build process was still going, just nothing new I did to ccnet.config made any changes.  I restarted the service, and it did one of those “the services has started and immediately stopped” things.  Didn’t throw any errors, just stopped immediately.  running ccnet.exe from the console pointed out the problem, and once I fixed the config file the service ran normally and my new xml files were being merged properly.  So if you start experiencing some weird behavior, the console app is great for debugging.

The docs in general for ccnet need a lot of work.  I won’t complain too much because it is a damn fine piece of software, and it’s free, and as such maybe it’s up to us to support it as a community, which is why I’m blogging it.  But when you’re running up against some problems, don’t take the docs for literal truth.

On the plus side, it seems like it’s much better with VSS now.  In 0.8 it didn’t always catch modifications to checkins, so the build wouldn’t always fire.  And it got to be a big hassle, which is one reason why I kind of left it alone and let the build process here fall by the wayside.  That seems to be resolved now, and it’s catching every modification so far (will most assuredly stop now…).