I got very far, but then I ran into a bug in the C# compiler. Imagine this query:
ILLBLGenProQuery q = (ILLBLGenProQuery)(from c in metaData.Customer
select c.Orders);
(Also goes wrong with prefetch paths, the point is the usage of a Related collection in the query, here 'Orders').
'c' is of type MyCustomerEntity, and c.Orders is defined in 'CustomerEntity', but overriden in MyCustomerEntity and a different attribute is applied.
However, the expression tree contains the PropertyInfo of CustomerEntity.Orders, not MyCustomerEntity.Orders. This is shown also in the reflector code of the compiled code:
ParameterExpression CS$0$0000;
LinqMetaData metaData = new LinqMetaData(adapter);
ILLBLGenProQuery q = (ILLBLGenProQuery) metaData.Customer.Select<MyCustomerEntity, EntityCollection<OrderEntity>>(Expression.Lambda<Func<MyCustomerEntity, EntityCollection<OrderEntity>>>(Expression.Property(CS$0$0000 = Expression.Parameter(typeof(MyCustomerEntity), "c"), (MethodInfo) methodof(CustomerEntity.get_Orders)), new ParameterExpression[] { CS$0$0000 }));
Here, you see that it does a methodof on the CustomerEntity type, which is wrong, as the type of 'c' is MyCustomerEntity.
This kind of sucks, as I now can't determine the type of the entity inside the collection, and the linq query can't be parsed.
I'll mail microsoft about this, and have to wait for that reply. I can't add support for two-class scenario in adapter for linq otherwise...
(edit) there might be a hack around this, with an own reflection call on the member, I'll try that and see if I can determine the attribute that way. The MS 'it's a bug' route isn't useful anyway...