Yesterday I mentioned that the file system source control provider in CC.Net was a little inefficient. I speculated as to how it might be working and how it might be improved. Well, as the saying goes, assume makes an ass out of you and me…
The file system source control provider is actually far far simpler than I expected. It scans the ‘repository’ file system tree and simply looks for files that have been written to since the last check.
Well, it’s about a month since I started running Cruise Control .Net and things have settled down somewhat now and I can almost go a day or two without tweaking my configuration or being tempted to fix issues in Cruise Control itself.
For those of you that haven’t been following along:
First I realised that the latest (1.3) release of Cruise Control .Net wouldn’t work for me without some hacking.
Barry (who seems to have stopped blogging) recommended this blog to me; Coding The Markets. It’s pretty good if you’re into investment banking development stuff.
If Richard Wolff is reading this then I can’t reply to your emails as your ISP is bouncing my emails with this:
`Hi. This is the qmail-send program at ns.mgf4.net.
I’m afraid I wasn’t able to deliver your message to the following addresses.
This is a permanent error; I’ve given up. Sorry it didn’t work out.
Connected to 207.115.36.23 but sender was rejected.
Remote host said: 553 5.3.0 nlpi100,DNSBL:To request removal of, 69.
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.
The free version of the socket server framework contained code that could cause a deadlock during connection closure if you also have a lock in your derived class.
There’s a lock taken out in CSocketServer::Socket::IsValid() that isn’t really required and which can cause a deadlock if you have your own lock in your derived class which you lock in OnConnectionReset() or other server callbacks and which is also locked when you call into the framework via Write() or other calls.
There’s a new release of The Server Framework’s Free Framework, here. This includes the bug fix that was mentioned here.
I’m working on the next releases of The Server Framework, and I now have continuous integration (of a sort) so my build and test problems are being minimised… BUT… Keeping Visual Studio 6 support in the framework is becoming a bit of a mission. It’s mostly simple template stuff that fails but I find that I keep having to work around VC6 issues.
I’m proposing to drop VC6 support from version 5.
I’ve been tracking a bug for a client recently and yesterday I got a remarkably similar bug report from one of the users of my free socket server framework. The client’s code is pretty old and was originally based on a server framework that was based on the free version of the code and it hasn’t been upgraded to the latest version yet. The bug in my client code is also present in the latest (Feb 14 2006) version of the free socket server framework - found here.
As I mentioned a while back, I’m writing a managed XLL style add-in system for Excel for one of my clients at the moment. This is going pretty well, most of the custom marshalling code is now done and we can write code in C# and expose it to Excel as worksheet functions.
Over Christmas I picked up a copy of Excel Add-in Development in C/C++: Applications in Finance by Steve Dalton.
