One of my Xmas hobby projects was to produce a WinForm GUI for creating and editing Microsoft SDC Build Tool configuration files – I really wanted to make it much easier for developers (and myself) to manage SDC build scripts – I’m sure I’m not the only person who gets giddy and disoriented navigating around any script that’s over 20 or so steps long. I’ve been ruminating about this utility for quite a while – and after my experience developing PeopleFinder – I decided that The Netron Project was the tool to use.
I based the Conchango.Build.SDC.TaskBuilder application on Francois Vanderseypen’s Generic Graphing Application that is supplied with the Netron.GraphLib SDK. After a few hours development I hit a problem – the custom properties of my TaskShapeBase Shape object were throwing exceptions when they were dragged and dropped on to the Graph Canvas – after a couple of emails to Francois (Thank-you!) he told me that the custom types my custom properties use would need to exist in the Netron.GraphLib assembly – otherwise the custom types wouldn’t be recognised upon reflection (hence why the Automata types are in this assembly). A few hours later I hit a second problem – I’d have to create my own serialization routine as serializing Netron Shapes hasn’t been implemented fully.
The Microsoft SDC Build Tools come with an XSD which describes all available tasks – I used XSD.EXE to generate a .cs file, then moved all enumeration types into separate class file and converted all the remaining classes into interfaces – thus defining the structure of the tasks. I decided to implement a variation of the Data Transfer Object Pattern – each Shape implements a specific Task interface (which defines the properties of the task) but also has to override and implement a method called public virtual object GenerateDTO() which returns an instance of a Data Transfer Object (DTO) which also implements the specific interface as well as all the XML attributes needed to serialize the DTO into the SDC confilg file XML format.
Creating a new Task Shape and DTO proved to be a quite time consuming process; Shape objects were between 100 – 300 lines of code each – overrides of base methods and lots of nasty repetitive plumbing. DTO’s were between 80 – 170 lines of code each – just lots of repetitive plumbing and Xml attribute decoration. On average it was taking me 40 minutes to create a new Shape object and 10 minutes to create a new DTO. The mindless grind was ok for the first hour or so(only because of the glorious programmable buttons on my IntelliMouse Optical), but the SDC Build Tools has ~28 defined Tasks and I knew that my enthusiasm would run out long before I completed the application.
Enter CodeSmith...
Within 90 minutes I had created a CodeSmith template that could generate any Shape Task, when supplied with
- The Netron.GraphLib assembly containing the Task interface definitions
- The name of the Interface to implement
- The name of the task
- The task description
It took a further 15 minutes to create a CodeSmith template for creating DTO’s (due to the large amount of reuse in reflection utility methods from the previous template) which simply required
- The Netron.GraphLib assembly containing the Task interface definitions
- The name of the Interface to implement
It took ~30 minutes to generate the remaining 28 SDC Task Shapes and ~20 minutes to generate the remaining 28 SDC DTO’s. That’s 155 minutes (or 2 hours, 35 minutes) in total.
If I had continued cranking the classes out by hand it would have taken over 1400 minutes (or 23 hours, 20 minutes)!
The diagram below puts those figures into perspective:
Because of CodeSmith – I have now almost completed the application (I will be releasing the source within the next few days, after a little more testing) rather than still having 3 working days worth of mindless copying, pasting and code plumbing ahead of me.
Using Code Generation to eliminate all the tedious, repetitive coding activities has startling benefits, especially if you are working on a project run using Scrum. If you have to deliver working, production quality code within 4 weeks and you can possibly make savings of days by using Code Generation – well, it’s something you should seriously start to look at.
My colleague Mark Harrison (no blog as yet – but he promised me he’d start soon) has been using Code Generation for the past couple of months – I sparked his interest when I bought a copy of Kathleen Dollard’s Code Generation in Microsoft.NET – since then he’s gone down Katheen’s XSLT Generator toolset route and I’ve gone down the CodeSmith one.
For more information on Code Generation take a look at http://www.codegeneration.net/