See also: http://boilen.codeplex.com/

Awe, poor little project — my free time and energy has shriveled up and I am officially abandoning the project to the wilds of the internets (though I would be happy to help anyone interested in taking over).

Instead, I'll be using the interesting StringTemplate library I learned about recently. ST uses a very clean syntax for applying templates embedded in plain text to data values you pass in. Of couse, being a general-purpose templating engine it does not have any specific code generation features builtin, but writing templates to support common features is quite easy (that is, once you get a handle on how their templates, groups, lexers, and loaders work together :).

So ST can handle the 90% case of automating common coding idioms, though it does miss out on some of the advanced features I wanted to include in ncodex. In particular, automatic addition of appropriate guards/input validation on public members (non-null reference types, efficient enum validation, range checking, etc); automatic handling of IDisposable implementation (IsDisposed property, proper methods, disposing disposable members, etc); and automating common design-time support based on members of the type being designed — all of which require type-specific information (i.e. this class I am generating and these members implement IDisposable).

And I do have some problems with the general usability of ST for .NET development:

• Doesn't target Visual Studio, requiring manual integration of template files and generation.
• No intellisense (mainly for spell checking: it is easy to mistake a "cannot find template ABZ" error for a loading problem, rather than a misspelling of template ABC)
• Plain-text parsing errors are not as friendly as XML parsing errors
• Have had some problems with calling nested templates, requiring restructuring of the template hierarchy

Still, these are fairly minor complaints, not deal breakers. And lets not forget one of the most important features: it works today, whereas ncodex would require many more weeks to get into a similarly usable state for all the 90% features :)

So, while I still think ncodex would act as a good .NET-specific tool for automating those common, tedious, robotic coding patterns, for now I have not time to invest in the project.