Frankly, I never liked Linq to SQL anyway. I used it once in a project of mine, and found the automatic class designer distracting and the LINQ code too underpowered and slow.

I think MS has done a good thing by killing LINQ to SQL. Not everything has to covered in layers of abstraction... Sometimes it makes things worse

Plain old SQL is the best.

Ayende

I couldn't agree more! In fact I am one such invested person as you described in the post and my face feels quite well spat upon. Why would I risk (given this behaviour) using the Entity Framework, for fear of having the same thing happen (I know it's not likely, but it exemplifies the point). Who knows how many other technologies may suffer this fate given the furious release speed and depth of new technology coming out of Redmond.

Seems like another case where Microsoft discovers "whoa, we are offering way too generic framework making our platform dangerously open for an easy integration with third party systems" and panics.

This is really disheartning. I was quite confused recently when I was starting a new project, about what tool should I use. One choice was Subsonic which I have been using with no problems at all for so long. Second choice was Linq to Entities and third was Linq to SQL. I settled for L2E even though I wanted to go with L2S. I was a bit apprehensive about the fate of L2S and all my fears came true. Too bad as I think L2S was really a good technology.

Are they really killing it?

"We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well."

That phrase suggests otherwise.

Added to that: Linq to Sql has by far the best Linq provider out there in terms of expression tree parsing and optimization. Nothing else comes close and definitely not the one in the entity framework.

I too found that post utterly stupid. "Listen to our customers", well, if you did that for once, MS, you'd learn that what you're doing isn't the way a lot of people want to go.

Linq to Sql has a few big flaws, but to me it was a better choice than EF, with its retarded designer.

That MS kills Linq to Sql wasn't that unexpected though. After Linq to sql was moved to the ADO.NET group, they didn't release any new stuff in the framework. Sadly for MS, the code is inside .NET, and can't be removed forever. So Linq to sql is still there but is now partnered with cell mates like ODBC, DDE, COM+, OpenGL etc.

Why don't MS just release killed frameworks as open source? That way the community can do all the hard work and customers who have invested in it aren't betrayed.

I've read somewhere that the LINQ to SQL originally was able to connect to more than just MSSQL provider but that feature was taken out the release product. I think it was just too good that's why MS decide to cripple then eventually get rid of it...

What? they decided to cripple and get rid of it.. so they can force you to buy the entity framework! .. oh wait - thats free, so it doesn't make sense.

Personally I see this as saying they want to focus on a single product, which makes sense..

I agree with you on this point. There is too much obsession with full-blown Data Mappers, while simple Active Record frameworks have their use and are just plain simpler for a lot of cases.

This attitude in MS is spreading.

Just the other day I discovered that Workflow Foundation 4.0 is NOT a successor of WF 3.0/3.5, but is a completely new platform, written from scratch. It allows using old WF activities but you must wrap then in special Interop activity.

And we have put a lot of investments on the WF 3.0/3.5 stack.

I agree with 'Stephen' (and not just because we share the same first name <g). L2S was likley first DB-limited so that it could only work with SQL2005 in order to give people a reason to look at EF if they needed to support non-SQLServer databases.

But when L2S adoption turned out to be high anyway b/c such a larger percentage of .NET devs work in shops with SQLServer backends and initial reaction to EF was....lukewarm...at best (people like me say its a terrible O/RM offering and people with no O/RM experience say its too steep a learning curve and too heavy-weight a new technology for them), I think killing L2S was about their only choice.

They cannot be comfortable about moving other products (Astoria, etc.) to the same EF/edmx-based model if EF adoption putters along at a low ebb for the next three years and so practicially speaking I think they had no choice but to kill L2S since its relative simplicity was 'poaching' EF adopters.

Never-the-less, I agree that this is going to leave all those L2S adopters out in the cold, but this is YET ANOTHER really great reason to isolate your data-access layer in a world of its own and to NEVER let it bleed into your other layers, no matter how seductively easy it might make some software development tasks. If people followed good design principles, this will be painful but not deadly to their projects.

I believe this decision is the right one. Linq to SQL is not very good for a number of reasons.

The real source of this problem was back when Linq to SQL was released, they should not have pursued two conflicting data access strategies. Linq to SQL was always going to be an interim solution while they got the EF out the door, but that wasn't made clear until some time after release, and even then the message was missed by a lot of people.

NHibernate all the way.

Hmm, I don't know what is all the hassle about? I see no show-stopping statements anywhere in the linked post. LINQ to SQL remains at least as is, which is quite enough for what most use it.

Similar thing with Workflow Foundation which will be completely rewritten in vNext of .Net Framework and the new one will be completely incompatible with the current one :-((

I agree it's a big mistake. Why in the world they decide to kill it ?

This is yet another blow for new technologies coming out of Microsoft. They just keep getting new things out of the door and if they will discontinue whenever they want to, who will ever invest in those technologies ? I also feel Microsoft is going too fast in releasing new buzzwords. Slow and steady always wins the Race.

Everyone is so into MS's Linq to Sql that they keep forgetting that

Mono HAS a working OpenSource "Linq2Sql" that used to be the dblinq project:

http://code.google.com/p/dblinq2007/

Works with MySQL, MSSQL, Postgres, SQLite etc.

Your post is totally wrong. NOWHERE in the article do they mention killing it. On the contrary, they're talking about future developments!

Se stackoverflow for more information: stackoverflow.com/.../is-linq-to-sql-doa

Your LINQ to SQL code will still work regardless of Microsoft's support... not like FOSS is free from over-hyped fashion trends--which often die off, leaving people with still-working but not trendy code.

This is not news - MS said from the very beginning that LINQ to SQL was a hack. It was a short term release to fill a specific need (LINQ to SQL Server). They always intended to replace it with Entity Framework.

LINQ to SQL was written by the SQL Server team - has NO provider model (third parties cannot extend it).

Entity Framework IS the provider model for LINQ. It is the only way a third party can write a provider into a model from MS.

I never understood why they released it in the first place. It looked like a short term hack written because EF was too far behind to release at VS 2008 release.

Jason,

Linq to SQL has a provider model. It was disabled by Microsoft for political reasons.

The solution is simple, do not rely on closed source software.

J2EE programmers never have this problem since Java is open source and Sun developers aren't as influenced by marketing/politics.

@Jason Short:

LINQ to SQL was written by the C# team (specifically Matt Warren with help from Luca Bolognese). It has a provider mode, which the SQL Server Data Programmability team disabled except for SQL Server.

I've been fighting the battle to aid LINQ to SQL in getting some "respect," in the way of development resources. See oakleafblog.blogspot.com/.../...g-linq-to-sql.html and oakleafblog.blogspot.com/.../...ork-posts-for.html

--rj

@James

Yes, J2EE programmers don't have this problem AT ALL because LINQ is simply not available on our plattform. Schadenfreude when you are actually worse off (SQL/JPQL in Strings, when do we want it? Now! How long do we want it? FOREVER!) is NOT a pretty picture,

Personally, I loved Linq to SQL. It was the first thing that got me introduced to nHibernate :) I haven't looked back since.

James,

Java wasn't OSS for a very long time.

Hopefully the next time a question like "what can I do to convince my boss to use NHibernate or iBATIS.NET over Microsoft Technology X?" shows up on the ALT.NET mailing list people point to this as an example.

somehow you've turned a conversation about linq into a list of all technical likes and dislikes, at least one of you is right, they never talk of killing linq2sql. do you have the 3.5 framework? ok then, not dead

Oren,

Yes, Sun to me just come off as more developer friendly though.

You'll probably never see .NET open-sourced and Mono doesn't count since they're so far behind and MS don't contribute much to it. Moonlight has just reached v1.0 whereas Silverlight is now on v2.0.

They don't suffer from NIH syndrome (MonoRail > ASP.NET MVC, NHibernate > Entity Framework, NAnt > MSBuild, NDoc > SandCastle etc.)

They actively go out their way to stifle competition and prevent interoperability.

They tend to promote good development practices in their documentation (design patterns, unit testing etc.) as opposed to MS who recommend using DataSets and stored procs for basic data access (yuck!).

I understand that MS is a business and businesses are there for only one thing; to make money. However, you are not forced to use MS stuff so you can't really complain when it comes back to bite you.

Sorry, that should be:

They DON'T actively go out their way to stifle competition and prevent interoperability.

Moonlight 1.0 equals to Silverlight 2.0, as far as I know.

This is a ridiculous misreading of their statement.

I really can't understand why Microsoft attempts to compete with the rest of the world in every possible area. They have built some interesting products, but last several years is a neverending stream of new technologies, products and buzzwords from the company. And the implementation is very much behind marketing. For me, it makes little sense to get too involved in newest Microsoft products, because they can be abandonned or undergo very unexpected transformations. I think it's because they want to keep their monopoly at any price and what's good for them isn't equally good for their customers. From their standpoint it's better to provide a crippled technology than to allow independent solutions.

BTW my friend works at Microsoft's EF team and some time ago they weren't sure which technology will be continued - EF or Linq to SQL. So now it's more clear...

wow... I have just seen this, and can't beleive its being killed already!! To be honest I am so glad I fought the urge to delve into LINQ TO SQL and try to learn it...

Err... I love how many comments there are on this thread, and all but two or three of them obviously didn't even read the linked page. That leaves only two or perhaps three of them pointing out what I'm going to point out:

NOWHERE in the linked post does MSFT say anything even remotely resembling the claims in Ayende's post.

Not that I use it or have any intention of doing so, but LINQ to SQL isn't dead. At least not based on the page Ayende linked to.

Looks like a retraction is in order.

Oh man.... I'm glad I've invested my time in NHibernate and only used Linq sparingly.

Microsoft is turning into a product mine field with deprecation written all over it. :-/ Feels like the days when DirectX DirectPlay API was deprecated.

Long live NHibernate!!! EF = Entity Framework = Epic Fail.

"I never understood why they released it in the first place. It looked like a short term hack written because EF was too far behind to release at VS 2008 release."

Linq to sql has many flaws but it's not a hack, not by far. EF's linq provider can't stand in the shadow of what linq to sql's linq provider can do, and it's very very complex to even handle all possible weird crappy queries left alone optimize them as well.

Linq to Sql has an internal 'IProvider' interface which is necessary to write providers for it. But that's not going to help much, the linq provider itself isn't capable (as far as I could see through reflector) of doing all the translations of linq constructs to any possible other database SQL dialect, as every DB has its own stupidities in its sql dialect.

@Jeremy: sure it doesn't say 'killed' but how many times has MS mentioned new stuff for Linq to Sql at the PDC?. ;). If you want to push a framework forward, you have to actively add new features, define a direction, goals, milestones etc. None of that is done with linq to sql, at least nothing is communicated to its users, while MS promises a lot of new things for EF v2 (which are almost all available already in the various o/r mappers today), but none for linq to sql.

Similar to remoting. Does remoting still work? Yes, and with the proper serializers you can make it very very efficient. Is it killed? More or less, it's WCF and XML all over the place (even the binary serializer in WCF goes to XML first... ) MS won't spent advertising dollars nor a lot of articles, examples etc. on remoting nor will they do that on Linq to sql.

I wonder if they will regret this decision in a few years. But we'll see. :)

Has anyone considered the possibility that Entity Framework is LINQ to SQL version 2.0?

I mean, sure, the Alt.NET community really hates EF, but they've never really been all that happy with LINQ to SQL, either.

And technologies losing support is par for the course in the .NET framework -- it's a constantly changing environment. It's not they update non-generic collections all the time, and yet some folks still use them. LINQ to SQL may not be updated again, but it's not going away.

"Has anyone considered the possibility that Entity Framework is LINQ to SQL version 2.0? "

Well according to the EF team it isn't an ORM so no not really, one is a big heavyweight badly thought through solution and the other was small/tight and a good v1 idea (despite bad guidance about drag and drop).

So no, not really.

Jeremy,

Read between the lines, and put the management speak filter on

As usual people start ranting and raving without bringing anything to the discussion (ie Java vs .NET).

My opinion is that the features of L2S will be incorporated inside EFv2... If you watch the PDC video of the EF Futures you'll have that exact same feeling.

To me it's not a big issue, L2S is not an ORM but was a nice DAL writing accelerator. If they make EFv2 a real ORM probably none will need to have a dynamic sql statement generator.

Simone, I'm sure in few years Microsoft will provide something usable, and possibly this will be the Entity Framework. But the blog clearly says that Linq to SQL is dumped in favor of the EF, and maybe in future they will listen to some user needs and provide some more or less sensible replacement (i mean it's clear after you filter out the double-talk). But listening to user needs is not the strongest point of Microsoft. These 'Program Managers' have never seen a real user, c'mon.

I can't believe some of you people. LINQ to SQL was garbage. I hated it. There are so many other OR mappers that are so much better. And how could anybody defend Workflow? Talk about another pile of garbage. Such a ridiculous amount of work to do even the most simple task. I hate it. I hate them both. Good ridden.

"Linq to SQL has a provider model. It was disabled by Microsoft"

Um, then it DOESN'T have one you can use, does it? If it is not supported or exposed by MS then you should not use it. You definately can't use it as a 3rd party developer for VSIP integration. It would be like using PINVOKE to call all sorts of undocumented MS calls, you would never get your app certified by MS.

I can write internal APIs all day long. That doesn't mean I ship them or expose them. Just because you can see something in Reflector does not mean it is usable, stable, or supported.

You're all a bunch of whiners. As far as I know, there's no such thing as 'killbits' in .NET Framework. Every new release is backwards compatible, so the System.Data.Linq assembly isn't going anywhere. Just because Linq to Sql won't evolve it doesn't mean it's dead, or you shouldn't use it. It's there, it works, why not use it?

I think a lot of people here have a misconception of the API design and management in the .NET framework. APIs in .NET aren't supposed to evolve much. I know it's very ambitious, but take for example XML. First you had System.Xml, then System.Xml.Xpath, then System.Xml.Linq. Maybe next release will include a new XML API, that doesn't mean you can't or shoudn't use System.Xml.

What Microsoft is saying is, if you want more features use EF.

dun forget Language "M"

I'm on the LINQ to SQL team and have posted a response at damieng.com/blog/2008/10/31/linq-to-sql-next-steps

[)amien

"Firstly we are going to make sure LINQ to SQL continues to operate as it should."

"Secondly we will evolve LINQ to Entities to encompass the features and ease of use that people have come to expect from LINQ to SQL."

"LINQ to SQL will continue to work and EF will better address the needs of LINQ to SQL users with each new release."

"This isn’t to say LINQ to SQL won’t ever get new features. The communities around LINQ to SQL are a continuous source of ideas but we need to consider how they fit the minimalistic lightweight approach LINQ to SQL is already valued for."

Reading the above statements by Damien, I am even more sure L2S would not be improved upon. The "but" in the above last statement says it all.

Although L2S will work as it does today, everyone does expect improvements. .Net 1.1 also worked and still works, but how many people use it today? For me, no improvements = L2S is dead.

PS: I switched back to Subsonic for my project.

@Yogesh so you're saying any classes in .NET that don't get new methods and properties in the next release are dead and you shouldn't use them?

LINQ to SQL is liked because it's lightweight and simple. We don't want to distract from that core principle.

[)amien

Yes, internally LINQ to SQL has a provider model that is closed. It is important to note however that writing other providers is a massive undertaking.

The SQL Provider represents about 70% of the runtime source code in LINQ to SQL and so re-implementing that is not trivial especially if you also have to write designer/mapping tools (they are SQL Server specific). It does a lot of magic to get those queries looking as good as they do.

@Roger: There are no other providers disabled - it was simply the interface that was made private.

@Ayende: As I'm sure you are aware from your work on NHibernate writing a provider is a very difficult task given the subtle differences in database providers.

[)amien

We've not said we won't add new features. What we have said is improving the core of LINQ to SQL and closing the gap to EF are the priorities for 4.0 right now.

We have a list of feature requests from a variety of sources. Some of these fit with the "lean and mean" approach of LINQ to SQL and others pull in a different direction. Guess which are more likely.

[)amien

Damien,

I am not challenging what you are saying but all I want to say is that L2S is not a class. It is a technology which has some limitations. A class and a technology in my terms are different. If I don't like a limitation of a .Net class, I can code a workaround or use a third party software, but L2S is a platform which I cannot extend. I will love to see the limitations being removed and new features added. I don't know about others, but I love L2S.

But anyways, I hope you guys will do what you are saying and someday L2S will get a v2. Better late then never. :)

I've just read this and looked up what LINQ actually is. From where i am standing it doesn't look too bad.

I got out of the MS software train back when VB6 was still new and every new release of Data Access Objects would completely screw my software. I am now firmly in the "other" camp: Java, Hibernate, Hibernate Search, EJB 3.0, Lucene, Eclipse, GWT, ExtGWT etc etc. You get the point.

I'd just like to ask this... Do you all still write applications that rely on SQL queries fired from input to the user? If so, you guys need to look at Lucene and Hibernate Search. This has revolutionized our software and the users LOVE it.

Hibernate Search integrates with Lucene transparently and indexes you entities for you. You then use a Google-like search syntax to find them again. It's truly fast !!!!

Anyway, i hope you all have fun with MS's next framework. And the next.... and the next .... :)

Damien,

Please, try to read your blog with a small screen, i.e. with a mobile phone(and mine is one of the larger, a N95 8Gb).

By the way, I quite liked L2S, I was planning to use it for a project of mine, kudos to Oren about this post (neuron jumping, Iain Banks gave a great description of how a kudos based society could work on The Algebraist).

Ale

I just completed building a web application using LINQ and VS 2008. I am very pleased with the results, and it took half the time it would have taken using plain ADO.NET. The only thing I can say about all these people not liking it, is that maybe they never really gave it a try, because it was different from the using ADO stuff in the .NET framework? I love being able to navigate the DataContext object and query straight from my code, instead of writing external SQL queries and executing them with dataTables and dataSets. I hope LINQ only continues to grow and maybe some of the disbelievers will catch on to this great development tool

I have been using L2S for a large project and have enjoyed the experience. Any difficulties I have had, have been a result of my not trusting the framework.

L2S is really nice but not complete and now it is the step child as the ADO.NET blog post shows. It is time to get nhibernate-linq to mature a bit further.

We all know how much Microsoft and ADO.NET team in particular listen to customers. There was a vote of no confidence in entity framework and they ignored it and started investing more in it. That pig is not going to become a quick rabbit, much less a racehorse. Starting with wrong concepts like one giant model that is neither relational nor object and adding more bloat doesn't give you anything useful. Yeah, now they say, they will look at the normal ORM scenarios. That is like building a race car on a 18-wheeler platform. If you are serious, throw the junk that people voted against out and start with something better.

Oren, when can we get a good drop of nhibernate-linq? Please tell us there is a holiday present waiting for us.

Well, It's good to know this, because means nhibernate woul be still around...but...It;s better to see our errors before and work hard whitout taliking to much, right now NH could loose all the clients if we did not fix the current problems, specially performance, and query generation n the last moment, I was working with webORb (for flex) with NH on the server side, it works, good , but we still need to improve before start to talk, and watch out with Entity Framework.

keep working it's better than keep talking.

@Colin Jack re:

"Well according to the EF team it isn't an ORM so no not really, one is a big heavyweight badly thought through solution and the other was small/tight and a good v1 idea (despite bad guidance about drag and drop).

So no, not really."

Wait, so if I search the ADO.NET blog, they'll constantly decry how EF is not really an ORM tool at all, right? So why is that not the case? A quick search turned up post after post about how EF is an ORM tool and the approaches they take to solving "ORM issues".

My statement was not a comment on the quality of either LINQ to SQL or Entity Framework, I was merely trying to suggest that Microsoft seems to think that Entity Framework is the ORM tool they want to use, effectively making it LINQ to SQL v2.0. Does that mean you can't use LINQ to SQL? No. Hell, you can still use Typed Datasets, if you're feeling particularly masochistic.

Or you can wait for LINQ to NHibernate.

BOOOOOBIES

--ok let the nerddom continue

Actually, this is great news.

It means I can and should ignore the new data access technologies coming out of MS.

NHibernate all the way.

Discontinuing future work on Linq2Sql makes sense. It's just too lightweight to handle a real domain model.

If I ever get hired by Disney and they need me to write an application for Mickey Mouse, I'd be sure to pull out Linq 2 Sql where I can totally disregard best domain modelling practices.

I am so dissapointed in Linq2Sql I'm afraid I can't give any other opinion on this technology while I'm still p#ssed off at the fact that I actually thought it could solve a specific problem I faced or that it had the proper support to help point me in the right direction instead if the "sorry it can't be done" reply (no not replies - as only one person saw the need to reply to my query and I thank you Damien - this is not directed at you - you cool ;-) Ok, enough sucking up.

I'm glad they pulling the plug, as for EF? I've added my signature to the Vote of No Confidence doing the rounds on the internet. Not sure if I can post links, so if you interested in the vote of no confidence in the EF, just google it and you'll find the information.

Craig, the mickey mouse gag slayed me....

Anyway I only today learned about MS plans (or lack of) for LINQ in a job interview of all places. The guy asked me "what do you think of LINQ?" to which I replied very enthusiastically "Love it". That was met with a grimace and "oooh" where then he told me that the inside scoop from MS was that it was to be discontinued.

For the record I was being sincere, I do love LINQ to SQL even though I had my doubts about its performance for large scale projects, I can see some performance lag in my very small scale apps.

Looks like I'll have to look into this NHibernate thing ;)

Here we go again:

1) LINQ to SQL v1 was written by the LINQ to SQL team, which was "owned" by C# and VB; which one owned it at any particular time depended on who needed the tighter turn-around during development. The LINQ to SQL team didn't work on either the C# or VB compilers. The current owner is the ADO.NET/DP org.

2) There was a provider model. There was also a different provider model being worked on by the ADO.NET folks. Having two different, incompatible provider models does not make sense for attracting third parties, and so the one in EF was chosen.

3) While Matt Warren was the architect, the PM was Dinesh Kulkarni, not Luca Bolognese.

4) EF was never "LINQ to SQL v2". It was developed in parallel according to different priorities and architecture.