I can't find any documentation on SerializationContext/Kind, so I don't know if I'm using it correctly. When I serialize ByReference, as I described earlier, I get a stream that appears to consist of nothing but internal pointers, and no actual data. I tried ByValue as you suggested, but formatter.Serialize throws this exception:

"Type 'Xtensive.Orm.EntitySet`1[[DOSerialization.Child, DOSerialization, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]' in Assembly 'Xtensive.Orm, Version=5.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c' is not marked as serializable."

Here are the two classes I'm using for testing:

[Serializable] [HierarchyRoot] public class Parent : Entity { public Parent() { } [Field, Key] public int Id { get; private set; } [Field(Length = 20)] public string Name { get; set; } [Field] public EntitySet<child> Children { get; private set; } }

[Serializable] [HierarchyRoot] public class Child : Entity { public Child(Parent parent) { Parent = parent; } [Field, Key] public long Id { get; private set; } [Field(Length = 20)] public string Name { get; set; } [Field] [Association(PairTo = "Children", OnTargetRemove = OnRemoveAction.Cascade)] public Parent Parent { get; private set; } }

You make some interesting points with your additional comments.

1. Using DO, our goal is to define an "enterprise data model" in code. (If we were using some other tool, we would perhaps take a different approach, but we want to see what DO can do.) We can compile for different platforms, but that doesn't mean that each platform/layer needs to register every class with DomainConfiguration.Types.Register. In other words, each database would only have the tables that are actually needed at that level. I don't know what the issues are with type identifiers, but we are trying to solve one problem at a time; I hope there will be a solution when we get to that point.
2. I agree that adding DO to the POS layer just to support deserialization is not a good idea. However, the POS layer will require DO for other purposes. Specifically, a POS register must be able to complete transactions even when there is no network connection. Transaction data must be stored locally until such time as it can be transmitted. The system we are trying to replace stores the transactions in a flat file. The new system will likely store them in a SQLite (or equivalent) database. So, the POS systems will use the Transaction portion of the larger data model to store data locally, but only needs to understand other classes, such as Customer, which are retrieved from other systems via messages and displayed, but never stored.
3. Our object graphs will be acyclic, so if I understand your point, I don't think it will be a problem.
4. If we can't serialize Entity objects, then DTO may be the solution. My concern is that our Transaction model, for example, has 27 classes. I need some mechanism to automatically generate and synchronize the DTO classes using the Entity classes as input. Automatically generated code should be able to load a DTO object from an Entity object, and vice versa. I think I can do this using #if, substitute base classes, and a separate project for the DTO classes; and a reflection-based cross-loader to move data between Entity and DTO objects.

I haven't given up yet on DO, but this is taking more effort than I had hoped. Perhaps there's a different approach I should try?