Framework Development - Code generation

Persistence frameworks, for rapid development, usually ride on generated code. I have worked with different tools, custom, commercial, that let you point at a database table, or an XML file and generate classes. They also generate stored procedures for CRUD operations.
We faced several decisions regarding such code generators - should we use Codesmith, or build our own? Should we integrate with Visual Studio? How do we make sure the spewed code is not modified, but is extended correctly? Do we use the table as the master schema or spew XML and then generate code from XML?

Integrate with Visual Studio
I think to have a code generator plug-in is very convenient and increases productivity remarkably. But it is also troublesome to install and to supply configuration. Plus it is overkill upfront. We will use an independent generator for now and then develop (or buy) a plug in separately later.

How to extend spewed code
I have seen code generators that use a XML, XSLT model to generate code; or use templated code (as Codesmith does); or just write out lines of code from a generator. In general, you spew code from a database table schema. Then you go ahead and write some business logic in the spewed class. But the spewed class may need to be respewed for additional modifications.
To manage this, some tools detect that the spewed class has changed and show a manual merging tool.
Ideally the class file should not be modified at all - but that is almost impossible to enforce. I have seen some good innovative solutions using partial classes (in .NET 2.0). You split the same class into a spewed, unchangeable class file and a changeable class file. You can add business logic to the changeable class file.
You can manage the same using a spewed, unchageable base class and a changeable sub class.
Visual Studio, of course, spews code all the time - when designing WinForms screens. In MFC using Visual C++, they would just request you not to change some lines.
I think actively trying to prevent developers from changing the spewed code is kind of overkill (atleast in internal applications). I think you can use a convention of storing spewed classes in a separate folder and then hoping that nobody changes them. On the other extreme, we can avoid spewing code at all; generate and compile the code dynamically during the build process using a custom build action. That makes sure nobody can modify these classes. (XML Serialization does something similar).
For now, I am tending towards a loose approach - we spew the code and hope everybody changes the subclasses (which are also spewed along with the base classes). If necessary we will tighten up later (by taking the person who changes the spewed code outside and shooting him).


XML is king?
One of the ideas is that we spew XML (with column names, datatypes) from the table schema and use that as the basis for generating code. This has its advantages - you can add some custom properties in the XML and regenerate code. What if you wanted a property to be readonly? You can add that as a custom attribute to the XML.
The core issue is that a table schema does not contain ALL the information that you can play around with in a C# class. As we saw, marking a property as readonly is an example. So, philosphically I like the XML file idea. But it is not practical to maintain a separate spewed XML file AND a spewed class file.
The problem is that people can mess up the XML and cause the table schema and XML to grow apart.

So, for now, no XML. We will be generating code from a generator; storing in separate folders; and then subclassing from these classes, if we want to extend them.