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.

I hacked another fix into CruiseControl.Net today and we now almost have an acceptable level of performance in my particular (some may say warped) circumstances. The trick was to hack the project trigger to be a “local project” trigger. By default the project trigger uses .Net remoting to talk to the CruiseControl.Net server where the project is hosted. In my case this meant that all of my project triggers (and there are lots!

I am intending to check out some of the other build servers that people have been suggesting, but today I was too busy with real work so I just left a cut down version of my latest CruiseControl.Net configuration running on one of my boxes and fixed a few issues whilst doing proper work most of the time… This evening I decided to go and look at why CruiseControl.Net scales so poorly and the first issue that I came across is the title of this blog posting…

I’ve almost got something that works out of CruiseControl.Net. Once I’d hacked in some fixes for the project triggers and other stuff that didn’t work the way I wanted it to I concentrated on generating the config files that I required and testing the system. The good news is that I now have an integration system that works, it can build, test and deploy libraries in such a way that dependent libraries and applications are rebuilt as new versions of deployed artifacts become available.

I’ve been trying to get my code to build with CruiseControl.Net this week. It’s taken longer than I’d hoped, but I’m almost there. It became easier when I switched from assuming various parts of CruiseControl.Net would “work as I expected them to” to assuming that I’d have to delve into the source and change things… On the whole I’m a bit disappointed in CruiseControl.Net. I’m sure it works very nicely for simple situations, such as where you pull everything out of your repository and build it with a single project, but, when you’re trying to do more complex things it seems to be a bit fragile.

I’m currently working on two new releases of The Server Framework, the first is a simple release to add support for VS2008 and the second is the next “feature” release. Due to the number of projects and example servers and supported compilers that I test with it can take some time to finalise a release; each example server has to be checked out, built in each build configuration with each supported compiler and then the tests need to be run… Last time I did this I had planned to put aside some time to sort out an automatic build to do it for me, this time I might actually do it…

One of the problems with iterative development of servers that include performance counters is that it’s quite easy for the counters that are installed on a machine to get out of sync with the counters that the server is actually compiled to use. As development progresses and new counters are added the counter dll needs to be uninstalled and then reinstalled so that the text strings associated with the counters remain in sync.

I picked up a book yesterday, Writing Secure Code for Windows Vista. Which seemed quite interesting, and was a nice slim volume that would slip into my hand luggage for my flight to Geneva on Friday night (yay first ski weekend of the season!). I’ve been flicking through it this evening and was interested in the “Standard Annotation Language” (SAL) for annotating unmanaged functions that muck around with memory buffers, it looked like a potentially easy adjustment to The Server Framework code which would possibly improve security and usability… Unfortunately it seems that SAL is only operational when you run with the /analyze compiler switch and that’s only available if you’re running an ’enterprise’ level of Visual Studio…