>EF and WCF are different animals with different purposes.
>

Yes, Craig, thank you, I know that :)

Let me try this again.

Historically, there is a pattern with the Microsoft development tools (and I'm sure other vendors have similar situations) that goes like this:

1) Developers need to accomplish a set of tasks.
2) The current tools have some functionality (that might be good, or barely OK), and requires some additional code and elbow grease.
3) Developers crafts solutions, share ideas on how they accomplished it.
4) Next release of the tool, the vendor implements new functionality that would have made lives easier and maybe would have precluded the need for additional hoops.

Now, depending on how good the new feature is in #4, developers might be saying, "geez, if we had this back in #2, we never would have needed all this extra code. We should look at expending some developer bandwidth to rebuild our stuff with this new feature.

OR...developers might look at #4 and say, "ok, this is nice, but we accomplished the same thing back in #2 with additional code, and this new stuff in #4 doesn't really buy us anything significant. Maybe we'll do a partial rewrite in a year and maybe we won't.

I dare say that a large number looked at WCF and had the reaction of the former.
I also dare say that a slightly larger % looked at EF and had a reaction a little closer to the latter.

Mind you, I have nothing negative to say about EF. I just don't see the compelling benefit of it, the way I saw the compelling benefit of WCF.

I realize this is branching out from the original topic. My only point is that there's a long history of new features coming along to replace older features that might have required more code and elbow grease. And sometimes the topic is quite controversial. Some people hate database triggers and loved the idea of Change Data Capture in sql 2008. Others looked at CDC and concluded , "thanks but no thanks, I think I'll stick to my triggers".