LINQ to SQL breaking changes from beta2 to RTM (compiled from my LINQ forum posts)
Now that we are in the final weeks of locking down for RTM, it is worth tallying up the changes. Since betas are a bit experimental and intended for receiving feedback, the fact that there are changes shouldn't be surprising but we could do a better job of communicating the changes to our best customers - beta users and early adopters who help us polish the technology and take us to task for anything wacky (not just buggy). So here is a humble attempt to take a step in that direction
This post is just going to be a bunch of links to posts that have already covered this on LINQ forum.
Beyond these salient ones, we are also working on a more detailed list to help you migrate smoothly from beta2 to RTM or to get your books, articles, blogs etc. in shape for .NET 3.5 / Visual Studio 2008 release. As I can scrape together some time, I am working on updating the LINQ to SQL paper that has not been updated since beta1 (so I won't even put URL for it until I do some badly needed updates)
This is really a bug fix but worth mentioning in case the erroneous result went unnoticed in your code on beta2 and the exception on RTM build surprises you:
The intent was to not allow "partial entities" created through object initializer in projection. So the following query should have resulted in exception:
var q2 = from c in nw.Customers
select new Customer
ContactName = c.ContactName,
City = c.City
Instead, in beta2, this query executed and gave n copies of the first object where n is the total number of rows produced by the generated SQL. This bug has now been fixed and the query will result in an exception. The main reason is that we don't want downstream confusion e.g. some path relying on Customer.Orders collection or an UPDATE statement created using uninitialized values. Of course, you can do the intended projection above with an anonymous or separate nominal type.
Mike Warriner pointed out another important one that I had missed: Beta2 dbml file needs to be opened and saved to get the right unicode encoding. On that note, as I have pointed out in the post, I would not use generated code from beta2 at all. I would suggest using the dbml file from beta2 project and regenerating code using designer (saving is enough to re-gen) or SqlMetal as appropriate. It is not a good idea to use the beta2 generated code with the RTM run-time.