Linq to Sql support added to LLBLGen Pro
Imagine, you're sitting at your desk and you're using the Linq to Sql designer in VS.NET 2008 and you have, say, 50 entities in your model. You're happy about how things are progressing. It took a while to get the model set up, considering the wicked table and field names they cooked up in the DBA dungeon, but after some swearing and too much caffeine, it's done. The model which is smiling back at you is what you had in mind.
Rain slams against the window and the DBA you have heard about but never had the chance to meet in person, walks into your office and with her whiskey-shaped voice she almost whispers into your left ear:
"Son, I've updated a few tables in your catalog schema, hope you don't mind. See ya!"
Before you can ask her why she found it necessary to do such a terrible thing to you, she's dissapeared, back to her basement.
In shock, you stare at your shiny Linq to Sql designer, in it your 50 entities in full glory. Which tables were changed? What has she changed? WHAT!? You start telling yourself not to panic, when the idea of checking manually each and every of those 50 tables for changes, manually rebuilding the Linq to Sql model, re-doing your inheritance hierarchies, renaming the fields is causing a slight increase in sweat production. Why did you decide to wear this grey shirt to work, today!
Sounds familiar? Well, every Linq to Sql user will sooner or later get into this position. The problem is caused by the fact that the Linq to Sql designer doesn't have a model refreshing feature: when the database schema changes, you can't simply say to the Linq to Sql designer: "Hey buddy, I heard from our DBA overlords that you've some work to do. Ping me when you're done, OK?" and you get your model refreshed with the newest meta-data from the updated catalog schema and migrated to that updated schema.
Luckily, we've a solution for you. Yes, honestly, we do. You see, the designer of our O/R mapper system LLBLGen Pro has model refreshing and migration built in, together with sophisticated name construction schemes and inheritance hierarchy migration. It also packs a state of the art, task based code generator engine. So we wrote, in a single day, a couple of templates for our code generator engine, which can now produce Linq to Sql classes and mapping files out of a SqlServer project.
This gives you the option to update your model with the updated database schema meta-data without blinking an eye. On top of that, the code it produces is generated by templates. These templates are extensible and as our code generator engine is task based, you can add whatever you want to the pipeline: checking out code, compile the end result, you name it. Of course, command line tools are provided so refreshing, migrating and re-generating the code is completely controllable from the command line. We already chopped up the single code file the Linq to Sql designer produces for you, so you don't have to deal with a very large file with the model: every entity gets its own class. The only downside is that you can't update your model in the Linq to Sql designer anymore. But, why would you?
The templates are currently in beta, and available for our customers. If you're interested in giving them a testdrive, but not a customer of LLBLGen Pro, no worries: leave me a message via the contact form or below in the comments and I'll mail you the template package so you can use them with our 30-day trial installation.
A small note for the people who see conspiracy theories in every corner: no, we're not abandoning our own framework. On the contrary 
. Linq to Sql users already use Linq to Sql, but as we can provide some additional tooling for those people, why not?