|
Malcolm,
First off let me apologize for the patch. I totally dropped the ball on it. Not sure if I even looked at it. I know the patch system here doesn't alert people to submitted patches (or didn't in the past) but if I said I was going to look at it, I didn't.
A lot of things have happened in the past year or two and it might make things redundant here. This might be paritally why I sat on the patch (besides being lazy or not reacting to it). There are a few competiting technologies that might make Tree Surgeon
obsolelte. So let's go over where things are in Visual Studio right now and what we might do about it from a TS perspective.
First off there's the T4 templating system that's now baked into Visual Studio. Scott Hanselman has a great post on it here:
http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCodeGenerationBestKeptVisualStudioSecret.aspx which has links to some tutorials.
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, 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?
|