There is a lot of misunderstanding on this subject. Even competitors of Microsoft seem to not understand fully what Linq2sql is made of or what it actually covers. One of these competitors is Vistadb that says on their product comparison:

SQL CE users will have to wait until the Entity Framework release before they can use LINQ against a SQL CE database.

I sent them an email to warn them that their comparison was erroneous, and an exchange has started in which they've assured me I was in the wrong and have neither acknowledged the confusion nor updated their comparison. As such I feel inclined to bring the conversation to the community, to get knowledge out there. I have not received their authorization to reproduce the exchange, so I'll have to represent as accurately as I can, in my own word, the different points they made. And I hereby invite them, and you dear reader, to the conversation.

Before you begin reading this, please note I do like the work the vistadb guys have been doing, I think it's a great internal database, and I probably would use their product still. But with greatness comes responsibility yada yada.

There is no provider model in linq2sql

This is an easy mistake to make if you don't spend your time in reflector. Linq2sql *has* a provider model that has been marked as internal late in the process, as described on the Wayward Weblog. If I was to guess the reasoning, I'd guess that there would've been a conflict of interest for partners to support both the Titanic Entity Framework model that leverages updates to the core ado.net classes and a provider model where they would've had to rewrite the sql code generation from the ground-up in linq2sql.

But I would concede that, as it's not public, for all intent and purposes, there is no provider model *you can build against*.

Linq2Sql gives you a Visual Studio GUI and a mapping tool

This is accurate, and very relevant to our conversation. There is several aspects to linq2sql.

• A provider model, with a provider implementing access to Sql Server 2000, 2005 and 2008, as well as Sql Compact Edition 3.5. This is the bit of code responsible for translating between the model and the sql code
• An abstract mapping model defining types such as MetaTable, MetaType and MappingSource, that let you implement different mappings. Linq2sql ships with two of those, one for xml mapping files, one for attributes.
• Visual studio ships with a designer that lets you generate an xml mapping file through a point-and-click UI. This only supports the full-fledge Sql Server, and this is where the confusion may be coming from.

So there is a bit more than a GUI and a mapping tool. It's a GUI, a mapping model and a provider model.

Sql Compact Edition queries don't support Linq, the compiler does

Well I've struggled quite a bit to understand that one. Linq queries are compiled by the compiler as extension methods or interfaces defined by the implementations of Linq (Xml, object, Sql, etc). However, I fail to see any connection with Sql Ce itself, as the one querying the database is the provider that, indeed, supports Linq2sql just fine. The provider is indeed distributed with Sql Ce 3.5.

Microsoft does not use Linq2sql as a term that covers Sql Compact Edition and it's unsupported

I don't see how it relates to the technical conversation. And the download page of Sql CE 3.5 specifies the following.

SQL Server Compact 3.5 introduces a host of new features including LINQ to SQL support

Again, it doesn't seem like unsupported to me.

Conclusion

Vistadb is a strong product in its own right. The product comparison however contains a mistake and the company hasn't responded to the two emails I've exchanged with a catchall email address.

All in all, this highlights two points. Microsoft has a communication problem around Linq2sql; Iif your competitors don't understand your product well, imagine your customers. Secondly, if you want to put product comparisons you should *really* double-check your facts. Responding in person to emails rather than through a customerservices@... address, and double-checking before responding the second time would probably have kept me a bit happier.

This is in substance the bitter taste that's left in my mouth as EF v1 gets ready to be released.. I've been debating on this topic in user groups, meetings and within my clients: adopting EF as it stands would be a mistake as it introduces fundamental issues in the way we write code and in the way we design our architectures. We will spend years undoing the massacre done by introducing that technology as it stands, just like we still have to suffer DataSets today.

That's why I signed the ADO .NET Entity Framework Vote of No Confidence.

And today, it was announced that the Entity Framework team would adopt a transparent process in the same way as the ado.net data services team has. In this respect I'll have to remark that the ado.net data services team took the decisions they wanted to take, even when the community advised against them.

Furthermore, the objections that were made against the Entity Framework have been around for a while and apparently didn't make it into the V1.

I'll try and have an open and positive attitude towards this opening-up, but I'll notice that already there's a push within MS to adopt the entity framework everywhere. If you push for adoption of your v1 in the company and respond to criticism by promising to fix  fundamental scenarios in v2, you're doing more damage than good, and this is why I have a trust problem vis-a-vis the Entity Framework and its design team.

I know, some of you think that the browser control in the latest WPF 3.5 SP1 is the dog's bollocks. Sadly, it suffers from its origin as a wrapper around good old GDI and the lack of GDI redirection imposed by supporting WPF in Windows XP environments.

One thing I keep track of very closely is what the mono guys do. This is a fantastic pool of resources, skills and code, and if I had time to hack I'd probably join one of their many projects. And on their feed I came across Alp's post describing a WebKit-based 3d web browser. I can't wait to have a play with the code.