Linq to SQL Class Regeneration

Question

I've been using this nifty LINQ to SQL tool for a data access layer in an asp.net project. I keep making changes to the underlying tables and in order for the data classes to recognize the change I have to delete and readd the table which has changed. Is there some shortcut to regenerating the data layer?

Answer 1

You could use sqlmetal which is the command line class generator for linq to sql classes.

Answer 2

I've run into this same problem and using sqlmetal is definitely a good way to solve it. One approach is to create a batch file that executes your sqlmetal command and that way you can just run the batch anytime you need update your Linq to SQL classes, but what is even slicker solution is to use Visual Studio's Tools->External Tools function to create a command in Visual Studio that runs sqlmetal with your parameters. This works great and you can even drop the created command onto your toolbar for single-click rebuilding.

Answer 3

For situations/models where SQLMetal don't quite cut it, e.g. due to different naming conventions in the database and your model, or some other customizations in your L2S model I have an add-in for Visual Studio that adds commands to synchronize your L2S designer with the underlying database [schema]. (plus a bunch of other L2S and EF related features)

You can read more about it, download it and get a 30-day trial license from http://www.huagati.com/dbmltools/

Answer 4

LINQ to SQL version 1 does not support detecting database schema changes. The only way to have the generated classes modified is to regenerate them with either the designer or SQLMetal.

Keep in mind that there are not many differences between SQLMetal and the designer, the designer is a more 'pretty' UI for SQLMetal, and hides many of the command line switches.

I use the designer as I'm too lazy to constantly load up the command prompt.

In addition, make sure that you don't write any of your own code into the generated classes, otherwise you'll loose it on a regen. All generated classes are partial which means you can easily add your own extenders in a separate file.

Answer 5

In the past where I've worked, we created a wrapper class to the DataContext that sqlmetal generated. Then we created a thin data layer that kept private the DataContext and all the classes generated by sqlmetal.

If any operations in the software needed information from the database, they had to go through this wrapper layer to get it. In other words, no LINQ to SQL could appear outside of this data layer.

That way, whenever we had to regenerate classes via sqlmetal, only portions of the data layer could break. Much easier to fix one layer where all the data access code is than to change sprinkles of LINQ to SQL throughout your logic or application domain.