Uh, something wrong here...
I downloaded VS 2008 from MSDN in November, and have been using it happily ever since. It may have just become available retail, but I don't think this is news.
Microsoft's Visual Studio team has put the database division to shame. Days after Microsoft slipped out the news that the update to SQL Server will not be ready in time for next month's big-dog release event, Visual Studio 2008 has been released commercially - ahead of time. Visual Studio 2008 is available for purchase under …
... that LINQ is a 'functional language' addition for languages running under the CLR - not a database wrapper. LINQ for SQL provides limited object-relational mapping and introduces a whole heap of problems that don't have industry solutions yet. Just take a quick oogle at "disconected entities LINQ" and try to figure that issue.
I think there is some confusion in a lot of Register stories about the Microsoft launch.
The events that are taking place from February until May around the world are *product launches*, i.e. marketing events where MS goes around the world to spread the word about them. (Similar to car companies showing off their latest models in car shows around the world. Some of these cars you see there might already be available to buy, others might come out several months later.) So it makes sense to show these products together since they are all related and belong to the same generation. And it makes sense to *release* each product when it's ready so that people can start using it, instead of waiting to release them all together.
MS simply has the best development tools period, which is aggravating, because they are the only thing keeping me from switching to unix after this Vista BS. LINQ is probably the biggest change to any programming language since C++.
I do also have to agree with Neural9. There are allot of problems with O/R mapping in general. I would still stay with DataSets for disconnected data, but in dropping support for .ToDataTable(), MS has crippled LINQ over DataSets severely. Personally, the problems I've been having are with massive amounts of queries being generated because of lazy loading grandchildren:
http://codebetter.com/blogs/david.hayden/archive/2007/08/06/linq-to-sql-query-tuning-appears-to-break-down-in-more-advanced-scenarios.aspx
If you're using DataSets to serialize data from one component to another ... or even worse, from one machine to another, you're may be paying a SERIOUS overhead for the privelige.
While the paper that Ingo Rammer and I wrote on this subject was based on .NET FX 1.1, many of the principles remain the same. I'll try to find the cycles to convert the code to NETFX 3.5 and see what the results look like with today's technologies including WCF.
http://msdn2.microsoft.com/en-us/library/ms996381.aspx
From the link you posted: "ADO.NET DataSets provide a great way to retrieve, manipulate, sort, and shape data, store it locally for offline use, and synchronize changes back into a central database."
If you exlcude the Schema info from the DataSet serialization, and enable IIS gzip compression then the performance will increase dramatically.