I'm in the philosophical camp that considers code generators to be "wrong", because they indicate something that should be made part of the language.
But it's been a big part of the Pragmatic Programmer's ethic to write code that writes code, and in practice code generation works well if the generated code is hidden by default. No matter how philosophically pure you want to be, the language will never evolve as fast as the problems you want to solve.
The code that gets generated when you build a Windows Form in Visual Studio comes to mind. You can look at the generated code if you want, but it's a better idea not to. Moving to a declarative language with WPF was superior, however, because it's cleaner and more reliable to manipulate declarative code programmatically than imperative code.
They should have done the same thing with LINQ-To-SQL classes. They need a declarative language for classes that just have properties and no custom behavior. It probably would make it easier to make those entity classes dynamic--changing automatically when the underlying database schema changes.
We tried using CodeSmith to generate .NetTiers classes for all the tables in our database, but ran into two issues:
.NetTiers was bloated, and the code generated was enormous. I think code generation tools make it too easy to creature feep.
Because the schema was being actively developed and revised, we had to regenerate a lot, too, and that ended up making it very difficult to keep everything in source control because all the files were being regenerated and replaced. I ended up being unsure if the generated code ought to be in source control at all.
The best place for code generation should be in the compiler or the build phase, not the design phase. When you use an anonymous type or method in C#, the compiler is doing code generation on the fly. If you generate code during the design phase, you get a chunk of stuff that must be regenerated every time the underlying parameters change.
