Tree Surgeon Design Roadmap

Jul 4, 2008 at 12:45 AM
I wanted to capture my thoughts around where I wanted to go with Tree Surgeon here and if anyone had comments or ideas to contribute to it.

When TS was created, it was for a single target (C# VS2003 NUnit) and was easy. Just enter the name of the solution and bang! With additions we've done you can now generate 3 different source versions (VS2003, 2005 and 2008) and two different unit test frameworks (NUnit and MbUnit). There are plans for VB.NET support that has been asked, Gallio is on the horizon, MSBuild output instead of NAnt build files, etc. All of these outgrow the original design of TS and make it awkward from a design sense to keep adding on new parameters to the existing system. A bit of a redesign is necessary to accomodate the new growth in a well thought-out manner and potentially be flexible for future change (not future proofing here but looking at other unit test frameworks and even entire alternate tree structures).

TS uses the NVelocity generation engine for creating files and while it hasn't been updated in a long time (and probably never will) it works and I don't think there's anything wrong with it. The alternative is to roll our own, and frankly why would you do that when something works.

This gives us the notion of template files which I think is fine because the end result of Tree Surgeon is generated files. Maybe the templates need to be a little smarter or more complex (NVelocity can do a lot more than what we're doing with it now). An idea is to take a look at CI Factory that produces lots of output files much like Tree Surgeon and see what Jay is doing there.

As for the various configurations, I'm still thinking to look at falling back to a plugin pattern for each type of output. A unit test plugin would be responsible for creating all of it's own output, whether that was a stand-alone file, part of another file (like a section in a .csproj file) or an entire set of files. It would also be responsible for it's own configuration and presentation (or communication with a presenter).

Anyways, this is just a beginning but some re-design is needed and it has to start somewhere. Looking forward to any thoughts or ideas you guys have on this.
Jul 4, 2008 at 2:26 AM
Just a couple things that came to mind...

a) For a templating engine, T4 (Text Template Transformation Toolkit) might be something to look at.

b) I like really like the plugin idea. I think you're right in that is probably one of the few viable long term solutions to deal with adding and changing tech. A publish API would allow anyone to plugin their own framework output as needed.

Maybe four plugin categories? Tree, Code, Test, Build? Wow... that makes my brain hurt trying to think about implementing that... LOL. But with IoC/DI that might be do'able (well it might be fun to try at least ;)

BTW, congrats on the recent release and for bringing this project back to life.

Take care,
Jul 5, 2008 at 2:34 AM
Edited Jul 5, 2008 at 2:34 AM

@Greg: Thanks for the info. Took a quick look at T4 but it seems pretty heavy for such a simple thing as Tree Surgeon is doing. I'll let someone else maybe take a stab at using it as it seems overly complicated. NVelocity is working and while it's old and has issues, it does the job today.

As for the plugins I'm starting work on this tonight. I like the list you provided so might break it out that way:

IPlugin - Generic plugin interface any plugin has to implement, provides facilities to be loaded and has a reference back to the Tree Surgeon host

ITreeSurgeonHost - Interface that will be passed to the plugin on registration to provide information from Tree Surgeon (application name to generate, UI hooks, etc.). This is how the plugin will talk back to Tree Surgeon.

ITreeGenerator - Additional plugin interface that can be implemented to generate the tree during execution

ICodeGenerator - Plugin interface to create code using whatever templates, language, etc. you want

ITestGenerator - Plugin interface to create test stuff (projects, unit tests, etc.)

IBuildGenerator - Plugin interface to create build files.

I'm thinking I'm going to surgically go in and find a single thing (say the build file) and "Plugin-cise" it. In the end we would have something like an TreeSurgeon.Plugin.NAnt.dll implementing IPlugin and IBuildGenerator, which would create the NAnt build file. Then someone could build a SomeGuy.Plugin.MsBuild.dll or something.

I see the core system being ripped out of Tree Surgeon and moved into a set of plugins pretty much getting the system back to what it is now, but now extensible. Then the fun will be begin and anyone can create their own generator and distribute it.

Tree Surgeon just needs some functionality to load the plugins and hook into them in the various generation stages and provide a way to get the plugins to register on the UI for people to interact with them.

Should be fun!

Jul 5, 2008 at 3:07 AM
LOL... that does sound like some fun coding... :)

At first thought (and without knowing the code ;) I like what I'm hearing and think you're on the right track, both with the structure and the implementation. Ripping out the current stuff and "plugin-cising" makes sense. That's a great way to ensure the interfaces implement the right stuff, etc, etc..
Jul 17, 2008 at 7:36 PM

bsimser wrote:

@Greg: Thanks for the info. Took a quick look at T4 but it seems pretty heavy for such a simple thing as Tree Surgeon is doing. I'll let someone else maybe take a stab at using it as it seems overly complicated. NVelocity is working and while it's old and has issues, it does the job today.

As far as template engines go, take a look at Terance Parr's StringTemplate ( It's powerful, yet lightweight. It was designed and written around the notion of strictly separating the model (logic/computation) from the view (the template). It was originally written in Java, but it's available in both a C# and a python version. StringTemplate form the core of the code generator in Terance Parrs ANTLR toolset for compiler construction.

Here's some StringTemplate examples:

Here's the papers describing StringTemplate:

Jan 9, 2009 at 1:00 AM
Hi Bill,

I have been working for a little while with an older version of TreeSurgeon and have made a few mods which may help add some of the flexibility that you need.  I have been meaning to make contact and contribute these back for a while, but work pressures etc have so far stopped me.

Basically my changes are to allow template definition in the config file e.g.

<item name="coreGuid" value="{GUID}" />
<item name="unitTestGuid" value="{GUID}" />
<item name="consoleGuid" value="{GUID}" />
<item name="nantDeleteClause" value="${directory::exists(build.dir)}" />
<template name="2008"
description="Visual Studio 2008 starter project" 
directory="resources\templates\2008" >
<directory path="resources\skeleton" />
<templateFiles readDirectory="true" />
<template name="2005"
description="Visual Studio 2005 starter project" 
directory="resources\templates\2005" >
<directory path="resources\skeleton" />
<templateFiles readDirectory="true" />
and use a templated tree using symbols in the directory and filenames instead of sappling.  I have modified the tree generator to walk the template directory tree and replace the wildcards with $projectName.  An exaple tree would look like this:


 The GUI front end reads template entries from config and presents them in a dropdown.
This means you can add a new template by adding a new template directory and adding its path to the config.

Let me know if you are interested in the code.

Thanks for keeping TS alive

Jan 9, 2009 at 6:50 AM
Hi Mike,

I'm very interesting in seeing your changes. Please feel free to send them to me via email ( as a patch or zip.