A few items here.

First, you may be able to do what you want by editing the XSD. I know there is a way to annotate the XSD so you can name the class and properties differently from the table/col names in the db. Then xsd.exe will read your annotations and gen code based on them.

Another approach people take with data sets is to seperate the Rules from the data set. Create a business object class which has the data set as a property. This allows you to have a base business object with abstract CRUD methods which you BO's derive from. Then, you can regen you datasets without loosing all your business rules.

Most of the business object's methods will accept or return the data set. The data set can be passed to the UI layer or the data access layer as needed.

See http://www.mssql.org/Uploaded_Files/BizObj.pdf for a more indepth treatment of this topic.

But, you may want to ask if you should really use the data set. As you see, it is hard to encapsulte the rules and data using a dataset. You can generate a bizobj that derives from a base bizobj class. This generated class will make each propert overrideable. Then, you derive from that class which is where you put your rules. Something like:

public class BusinessBase {

//This class will contain CRUD funtions and implementation.
}

public class EntitynameGen : BusinessBase {

// This class with be generated with overrideable properties
// You might want to mark this class abstract, cause it should never be instantiated.

}


public class Entityname : EntitynameGen {

// this class is where you will put your business rules.
}

So, with the above, you can regen the Gen class whenever you change your schema, such as adding a col or whatever. Of course, if you remove a col you may still have to manually remove any code looking at that property. Of course, when you compile you will get error messages to help you find those places.

Finally, as Dave said, the ultimate is to use an Object/Relational mapping framework. This allows you to map your Entity/Business objects to the data base. This has alot of advantages. The first being that schema changes don't mean you have to change your objects, just the mapping files. The other BIG advantage is that you are now creating an OBJECT centeric application rather than a data centric. Your object model usually won't map your data model. But, using datasets makes your wedge it that way and your object model is never optimal.

O/R mapping tools also eliminate the need to write SQL. You write Object Queries instead. Alot of folks don't like this cause it eliminates SP's and requiers the system have access to the tables. But, I've never considered this a problem.

Alot of proponents of O/R say that the programmers should create and optimal Object model and the dbas create and optimal data model, then you just create mapping files. NHibernate is a .Net implementation of hibernate from the Java world with is very widley used.

I hope this info helps. I didn't mean to open the whole architecture can of worms here, but it is important up front cause you will live with your apps architecture for a long time to come.

BOb