Hi,

In our project we are using LLBLGen 3.5 with WCF Data Services (OData) and WPF. This version of LLBLGen does not support Navigation Properties on subtypes YET, as described here: http://www.llblgen.com/documentation/3.5/LLBLGen%20Pro%20RTF/hh_start.htm :

"No navigators supported in subtypes.

This is a limitation of WCF Data Services in .NET 4. A future version of WCF Data Services will support this, and when this is released we'll look into lifting the filters we added to our code to filter out navigators on subtypes. This limitation means that if you have inheritance in your entity model, any subtype can't have a relationship with another entity, all relationships have to be defined on the root of the hierarchy. This is quite a limiting factor for many people. If you run into this, consider WCF Ria Services instead (or a normal WCF service)."

The future version you mention is WCF Data Services 5, which is a NuGet package, and which DOES support navigation properties on derived entities. Support for navigation properties on derived entities was added in version 3 of the OData protocol (see also http://www.odata.org/blog/2012/5/11/odata-v3-demo-services ).

Inheritance support

You can now address properties on derived types.

I have verified this with a unit test on WCF Data Services 5.

Below the supported versions of OData:

• .Net framework 4: OData v. 2
• .Net framework 4.5: OData v. 2
• WCF Data Services 5 (NuGet): OData v. 3 We are using .Net framework 4 together with the WCF Data Services 5 NuGet package.

Two questions:

• is it possible to disable the temporary filter mentioned in the quote above? Reason: we redirect some OData requests (http: //myserver/Services/DataService.svc/MyEntityNames?$expand=...) to our own OData feed generator class, but we pass the metadata requests (http: //myserver/Services/DataService.svc/$metadata) on to LLBLGen. However the our OData client throws away the navigation properties of subtypes because LLBLGen has stripped those subtype navigation properties off the metadata it returns.
• (when) will LLBLGen support WCF Data Services 5 - OData v.3? (as .Net 4.5 does not support OData v.3)

In our rather complex (/big) model I was able to refactor away some use of inheritance, but not all; therefore I still need to retrieve some subtypes with navigation properties.

Thanks a lot in advance.

aburggra wrote:

Hi,

In our project we are using LLBLGen 3.5 with WCF Data Services (OData) and WPF. This version of LLBLGen does not support Navigation Properties on subtypes YET, as described here: http://www.llblgen.com/documentation/3.5/LLBLGen%20Pro%20RTF/hh_start.htm :

"No navigators supported in subtypes.

This is a limitation of WCF Data Services in .NET 4. A future version of WCF Data Services will support this, and when this is released we'll look into lifting the filters we added to our code to filter out navigators on subtypes. This limitation means that if you have inheritance in your entity model, any subtype can't have a relationship with another entity, all relationships have to be defined on the root of the hierarchy. This is quite a limiting factor for many people. If you run into this, consider WCF Ria Services instead (or a normal WCF service)."

The future version you mention is WCF Data Services 5, which is a NuGet package, and which DOES support navigation properties on derived entities. Support for navigation properties on derived entities was added in version 3 of the OData protocol (see also http://www.odata.org/blog/2012/5/11/odata-v3-demo-services ).

Inheritance support

You can now address properties on derived types.

I have verified this with a unit test on WCF Data Services 5.

Below the supported versions of OData:

• .Net framework 4: OData v. 2
• .Net framework 4.5: OData v. 2
• WCF Data Services 5 (NuGet): OData v. 3 We are using .Net framework 4 together with the WCF Data Services 5 NuGet package.

The distribution system they've chosen is a bit of a problem, unless we can simply dump the meta-data into the containers without taking a new dependency on the v3 assembly. Because if we have to do that, we alienate everyone using Odata v2.

Two questions: is it possible to disable the temporary filter mentioned in the quote above? Reason: we redirect some OData requests (http: //myserver/Services/DataService.svc/MyEntityNames?$expand=...) to our own OData feed generator class, but we pass the metadata requests (http: //myserver/Services/DataService.svc/$metadata) on to LLBLGen. However the our OData client throws away the navigation properties of subtypes because LLBLGen has stripped those subtype navigation properties off the metadata it returns.

The code is in the metadataprovider class, line 951. There it checks if the navigator is in a subtype. If so, it skips it. There are 2 filters for this below each other.

I wrote the code without knowing the limitation, so it might very well be that by commenting it out, it simply works. If that's the case, it could be enabled / disabled with a setting. But I don't know what we have to do additionally. My feeling is that we have to reference a different OData assembly, namely not the one in .NET (like we do now), but the nuget one to make this work. (not sure, haven't looked at it since .NET 4.5 was announced and it didn't include odata3).

Could you create a debug build of the sourcecode which doesn't have the filter to test it with your application to see whether skipping the filters simply makes it work? (i.e. without referencing the new odata dll in the odatasupportservices assembly). If the odata v3 dll has to be referenced in your code, that's fine.

(when) will LLBLGen support WCF Data Services 5 - OData v.3? (as .Net 4.5 does not support OData v.3)

We haven't planned an update for v4.0 for this, as .NET 4.5 doesn't support it out of the box as well. But, if you can test for me that with the filters switched off and no need for us to reference the nuget based odata dll, I'm happy to add a setting to switch off the filters to the v3.5 dll and carry it over to v4

I asked a WCF Data Services team member (Mark Stafford) over twitter about this and pointed him to this thread. This is his response: https://twitter.com/markdstafford/status/263047895580803074

If it's not a drop-in replacement, which it seems not to be, we can only postpone the v5 build of the code to v4. However, we can direct you what to do with the current code in sourcecode form to remove the filters and recompile it against the v5 dll so you can start using it today.

OK, Thanks! I'll build a debug build with the two filter lines removed. Where can I find the source code of LLBLGen?

BTW: some time ago I tried to build LLBLGen with WCF Data Services 5 (Microsoft.Data.Services), but that does not work (I don't recall directly if I got a build error or exception). So I had to switch to System.Data.Services from .NET 4.0 (only for the web service, the client side uses WCF Data Services 5).

What I found out with my unit test: I created a unit test (web application project + client project) against WCF Data Services 5 nuget (for both the web application and the client). I created a navigation property on a subtype. That worked fine and the value of the navigation property was filled at client-side. Unit test looks like this:

public class Root
{ 
        public IList<Sub> Subs { get { ... } }
}

public class Super
{ ... }

public class Sub : Super
{ 
        public IList<SubRelated> Items { get { ... } }
        ...
}

public class SubRelated
{ ... }

public class MainContainer
{
        ...
        public IQueryable<Root> Roots { get { return Root.Instances.AsQueryable(); } }
        public IQueryable<Super> Supers { get { return Super.Instances.AsQueryable(); } }
        public IQueryable<SubRelated> SubRelateds { get { return SubRelated.Instances.AsQueryable(); } }
}

public class DataService : DataService<MainContainer>
{ ... }

Then I removed WCF Data Services 5 (Microsoft.Data.Services etc.) assemblies from the web application and added the .NET 4 WCF Data Services (System.Data.Services etc.) assemblies. The client remained on WCF Data Services 5 nuget. I got the following results:

• web browser: .../DataServices/DataService.svc works fine.
• web browser: .../DataServices/$metadata. Works fine too (!)
• web browser: .../DataService.svc/Roots?$expand=Subs throws an exception:

"Navigation Properties are not supported on derived entity types. Entity Set 'Supers' has a instance of type '...Test.Reflection.Sub', which is an derived entity type and has navigation properties. Please remove all the navigation properties from type '....Test.Reflection.Sub'

• data service client: dataServiceClient.Roots.Expand("Subs/Items").First() throws an exception:

...Tests.Reflection.GetServiceData.GetSubs: System.Data.Services.Client.DataServiceQueryException : An error occurred while processing this request. ----> System.Data.Services.Client.DataServiceClientException : <?xml version="1.0" encoding="utf-8" standalone="yes"?> <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <code></code> <message xml:lang="en-US">Type '...Tests.Reflection.Super' does not have a property named 'Items'.</message> </error>

However, because we generate out own OData feed, I would still like to use the metadataprovider without the two filters.

Thanks.

The sourcecode is available in the customer area, under v3.5 -> extras section.

Yeah, it sometimes works with odata v2 and sometimes it doesn't, hence we disabled it altogether also because MS said it wasn't supported.