Linq to Sql doesn’t play nicely with disconnected layers and you can read about it all over the place. In addition to this you might also encounter the infamous

Object reference not  set to an instance of an  object

when trying to use the InsertOnSubmit method of the data context inside a workflow. While this same method works perfectly outside WF it seems you need to have the

[DataContract()]

attribute on your entities in order to convince Linq2Sql to insert the entity. In the designer this amounts to set the serialization mode to Unidirectional (what’s in a name…). All this comes as a surprise to me since I was looking at data contracts as part of the WCF world.

Finally, there is also the minor but annoying problem that Linq To Sql entities include properties related to the associations you have in your Linq2Sql design. For example, if your entity has one property (corresponding to one database field) but many foreign keys the generated entity will have multiple properties which inevitably leads to problems when trying to use them inside a workflow transaction. Hence, the only way is to extend the generated entities by means of a partial class construct and implement the ISerializable interface (i.e. hand-crafted serialization).

All this leads somehow to the conclusion that Linq To Sql was really not designed well to fit with the rest of the .Net 3.5 framework. Great idea, but not too well implemented. Let’s hope the final release of the Entity Framework (around august with .Net 3.5 SP1) will bring some cures.