LINQ to XML has suited my needs just fine.

Thanks for the comments. I have tried to reproduce the bug that you described, but I cannot, nor can I find anything on Connect about it. Maybe we can talk later about it.

If you are interested in the minutiae of stored procedures in LINQ to SQL then check out ScottGu’s post here. Look for the section called “Mapping the Return Type of SPROC Methods to Data Model Classes.”

HTH,
David

The tool has been designed to account for your scenario of updating sproc return types as well as the rest of the model, even in cases where your return type was mapped to an entity type which represents a table but must now be mapped to something new because of changes to the sproc.

I do have a question for you. There is a pretty nasty bug in the DBML designer when setting some connection string settings. Basically what happens is everytime you make any changes to the DBML the option that sets whether you store the connection string in the App.Config or not keeps getting set to True! Since we use it alot at work we have to explain to every new developer how to work around this bug… which basically is change the setting back to False everytime you open the DBML file. Do you think your Fixup can solve this issue? Message me sometime if you need more details.

If you want a new topic for a screencast, how about ‘how to map your own custom entities to stored procedures using LinqToSql’ instead of the autogenerated table ones! I have yet to figure it out and thats why I have been playing with code generation these days.

In the past to help optimize my data layer, I have selected additional information in stored procedures and had to perform manual operations on the result sets. I found myself returning the same information in several stored procedures, so I created a Class in the designer and mapped the generated methods’ return types to that Class. I don’t know how common of a practice this may be, but I’m curious as to whether your tool could keep that information synchronized as well.

@RyanTheRobot: I don’t know that I’ve ever encountered a time where I did not have to “fixup” a LINQ to SQL model. While I may not use LINQ to SQL that often, I believe this tool will be invaluable whenever I do choose it as a persistence strategy.

Personally, I have encountered this with the Entity Framework tools because of a bug that prevented us from using the “Sync Model with Database” feature. And let me tell you–it was very painful.

But don’t take my word for it: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260723