The august issue of MSDN Magazine has an article on XSLT-based code generation. This is similar to some of the techniques I've included in my own code generator which I've been working on in my 'spare time', and plan to release as a .NET workspace. Both the MSDN Mag generator and my generator transform a SQL Server database schema into an XML document. There are a couple of ideas I might pick up on in the example in the MSDN. I use the DMO to gather database schema meta-data, but Peter Ashley in the MSDN Mag uses a stored procedure and SQLXML. I'm not sure about having to have SQLXML installed to use this. It is easy enough to turn a dataset into an XML document, and then I wouldn't need the DMO (which seems slow, and adds another dependency to my generator). My generator has a more modular architecture for doing generation once you have the schema, but this would have been out of scope for the MSDN article.
Code Gen seems to be coming ubiquitous in .NET. Not a day goes by where I don't see or hear of some tool for generating something.John Lam's weblog is a good source of information. I'm giving a talk on code generation in .NET in October at the local MSDN users group. It will certainly be interesting to see where all this ends up.
On a related note the september issue of MSDN mag has an Infopath article by Aaron Skonnard. Can't wait for that one.
Update: I'm a little disappointed in the UI code generated in the MSDN Mag article. It is more like classic ASP written in a strongly typed language (in a COM object for example) than ASP.NET. It uses response.write to create a stream of HTML that is sent back to the browser, meaning that it cannot utilize most of the improvements that I've gotten so used to in ASP.NET. Generating code in a flexible manner in ASP.NET seems hard because to do it properly you really need to generate two files for each page, the code in front and the code behind, and reflect changes in one in the other. If you want to allow users to edit the templates you create you need some way to automatically "pick up" controls they may add to the page (so they can be included in the code behind you generate). I've written two different ASP.NET form generators (which are included as plugins to my code generator). One is C#. It creates the code in front and uses CodeDom to generate the code behind. I've tried to make it customizable as much as possible via CSS, inheritance, and using placeholder controls to allow them to add a header and footer, but ultimately the developer doesn't get much of a say in how the form is structured. The other generator I've written is just XSLT. It gives ultimate flexibility in tailoring the code in front, but makes no attempt at generating code behind. The best idea I've come up with so far is somewhat convoluted. Generate code in front using XSLT, or something else the user can tweak to their heart's content. Create a skeletal code behind file. Compile. Host the ASP.NET runtime and create an instance of the page. Use reflection to look at the members in the page instance that are not in the code behind instance. Create a more complete code behind instance. See....I told you it was convoluted.