Tree Surgeon–Alive and Kicking or Dead and Buried?

Tree Surgeon is a Visual Studio project generation tool originally written by Mike Roberts based on a series of blogs he wrote about building up a maintainable and testable development tree for .NET projects (recreated here on the CodePlex site as Mike’s original blog content is gone).

It’s about building up a development tree that’s consistent from project to project; contains source code and all tools and dependencies; checked into source control; atomically integratable (not a word) into a build system complete with unit tests and artefacts (a word but the Canadian version of it).

This is something every developer does on day 0 of the project. So why not automate it and make it a wizard that you don’t have to think about a lot? That’s why Tree Surgeon exists.

I took over the maintenance of the tool and blogged about it back in 2007 when I took over the project and the last release was in June of 2008. The project has been popular. Since it’s launch there’s been over 10,000 downloads and 150,000 page views with 50,000 visitors to the site.

Times have changed. Since that last release in 2008 so much has changed for .NET developers. The question is, today is the project still viable? Do we still need a tool to generate a project tree given that we have things like scaffolding systems, NuGet, and T4 templates. Or should we just give the project its rightful and respectful send off as its had a good life and has outlived its usefulness.

What’s changed since 2008? Plenty.

First off there's the T4 templating system that's now baked into Visual Studio. Scott Hanselman has a great post on it here which has links to some tutorials (and his post is from 2008 but still valid today). From first glance at T4 (and to be honest I haven't done anything except tinker with it) it looks like Tree Surgeon. The templates look pretty much like what we use, except we're using code to search and replace tokens. With T4 it's built in.

Now having said that you still need to do some magic with T4 templates to make them work as they can't tell if you wanted this type of project or that type. If TS was written today, it would probably use T4 as the templating engine instead of the one it uses now. That would eliminate a lot of the heavy lifting and probably make the system a little more robust, dynamic, etc.

So there's that.


Then there's the elephant in the room, NuGet.

I personally worked on NuGet with Microsoft and have a lot of passion for it. With NuGet you can just type something like "Install-Package ScaffoldApp" and have a complete application built out for you. Scaffolding is something that was introduced with ASPMVC but it's a fairly generic concept and basically what Tree Surgeon does. With NuGet, scaffolding is easy and you just have some scripts and whatnot combined with files (potentially T4 templates) and the system will build out for you.

Early on in NuGet I considered that TreeSurgeon could just become a NuGet package. However at the time it was still difficult to get something going (NuGet requires a project to start with so that was a bit of a show stopper). However some other scaffolding systems seem to work well (the MVC ones come to mind) so there might be an opportunity there. The other option is a Visual Studio plug-in as there are a few that will create new projects for you (the HTML5 one comes to mind) complete with all the fixings.

In any case, if a new project was created in Tree Surgeon, I'm almost certain it should use NuGet to fetch the third party references.

Herein lies a bit of a dilemma with TS. For example when I start a new project I just go through the File > New Project and pick some appropriate starter (say a Windows Phone 7 application). Depending on the app platform (WP7, Web, WinForms, WPF) there are a set of packages that I'll just go and install (like Ninject or MVVM Light or something, along with some platform specific ones). It takes me 5 minutes but then I've got a scaffolded project that's ready to go (ala Tree Surgeon).

However two things come to mind. First off, these are installed with NuGet and some people still haven't jumped onto that band wagon. So I think there should be a decision here. Tree Surgeon requires NuGet. That way, the dependencies and whatnot for getting these packages works. That's one of the issues with the current codebase (and why talk of a plugin system was going on). The third party components come and go. We need a system to manage them without having to get a new version of Tree Surgeon every time a new build tool comes out. That plugin system was NuGet (except Nuget does it much better).

Okay, getting past that hurdle then the issue of how to serve up the tool so that a) its easy to get/use/access and b) it supports all the configurations that are out there. There are a lot more platforms than when Tree Surgeon started. TS was meant to be a solution starter so it would create your app along with unit test project and a client. The only problem is things like ASPNET MVC came along and already has the unit test framework generator built into the project creator. That sitll leaves WinForms and WebForms projects in the dust though and future of some of these (how many people start WebForms projects these days and where is WinForms going to be in a year when we have Win8 that doesn't support creating them in VS2012).


Pile on top of that the multitude of platforms available now. WPF, SharePoint, Silverlight, MVC, WebForms, WinForms, WP7. How many and how to support/include any or all of these in Tree Surgeon.

Maybe I'm making a mountain out of a molehill but the landscape has changed and I think Tree Surgeon needs to change with it. The question is in what direction?

There continues to be questions asked about creating new projects on StackOverflow for example, all of which either refer to or are similar to Tree Surgeon:

So like I said, there’s still interest and need for such a tool but is that Tree Surgeon or something else?

I look forward to anyones contributions to the discussion either in the comments below or on the CodePlex site here.


1 Comment

  • Hi Bill

    If I haven't said it, I'm interested.

    Maybe we start TreeSurgeon 2.0 or something like that.

    I just know that when I start a solution, I find myself going and grabbing a version of tree surgeon hitting build and then moving forward with a migration.

    Tree Surgeon, for as simple a tool as it is, has made a big enough difference in my development life, that I would like to be able to be part of keeping Tree Surgeon alive.

    The current version *can* be used to get someone started, so it might as well be kept undisturbed when moving forward.

Comments have been disabled for this content.