One last thing. Depending on how integrated you want your tools to be, you can "inject" your modifications to the dataset code via:
- regular expressions. Typically I'm searching for individual datarow classes, and injecting my interfaces at that point. The nice thing about interfaces is you can declare the method "private", give it whatever generated name you want within the "implemented" code. So, I'm never modifying the original dataset code, I'm always "injecting" my new methods. - codemodel. If you are willing to explore doing VS.NET add-in's, you could probably load your "divorced" dataset code file into a codemodel, and inject directly. This would probably be easier if you want to actually modify existing methods, and inject code into those methods, rather than simply add new methods. Personally, I started down this path initially, but in the end moved my logic to a stand-a-lone tool that can be run via command-line, batch build, or as a manually added VS.NET tool entry. It also assisted in doing unit-testing on it's supposed functionality. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
