The property 'EntityState' is not valid? RRS feed

  • Question

  • Here is the scenario:

    I have Entity Framework on my Data Layer with a generic Repository object (to handle standard functionality with EF), and in my business layer I am writing several business classes to encapsulate working with a repository object (that holds the EF Object Context as a property and handles CRUD and Error Trapping to one Entity) in this business object (per major entity).


    To the point, I have tried EVERYTHING to get the simplist scenario to work, but every step of the way, ADO.NET Data Services and EF are always continuously giving me headache to play together in a non-demoware fasion.


    So my base architecture looks like the following:
    {EF}  -> Generic Repository Object(Data Layer) -> Business Object (Business Layer)


    I have properties at this point that return ALL of the entities from my EF Model (just to see some positive results). I added this Business Object as the provider for ADO.NET Data Services. I also implemented the cryptic and -no documentaion- implementation of the IUpdateable and IExpandProvider to allow me to basically encapsulate EF and point my SOA to the Business Objects that contain all of the validation and domain logic.


    The Problem: After several attempts to get this service framework to just DISPLAY the tables (at this point I am just regurgetating out the Entites in my BO to see it work), I now get this error:

    The server encountered an error processing the request. The exception message is 'The property 'EntityState' on type 'Net.Membership.Data.Model.Membership' is not a valid property. Make sure that the type of the property is a public type and a supported primitive type or a entity type with a valid key or a complex type.'. See server logs for more details. The exception stack trace is:

    at System.Data.Services.Providers.ReflectionServiceProvider.BuildTypeProperties(ResourceType parentResourceType, IDictionary`2 knownTypes, Queue`1 unvisitedTypes, IEnumerable`1 entitySets) at System.Data.Services.Providers.ReflectionServiceProvider.PopulateMetadataForTypes(IDictionary`2 knownTypes, Queue`1 unvisitedTypes, IEnumerable`1 entitySets) at System.Data.Services.Providers.ReflectionServiceProvider.PopulateMetadata(IDictionary`2 knownTypes, IDictionary`2 entitySets) at System.Data.Services.Providers.BaseServiceProvider.PopulateMetadata() at System.Data.Services.DataService`1.CreateProvider(Type dataServiceType, Object dataSourceInstance, DataServiceConfiguration& configuration) at System.Data.Services.DataService`1.EnsureProviderAndConfigForRequest() at System.Data.Services.DataService`1.ProcessRequestForMessage(Stream messageBody) at SyncInvokeProcessRequestForMessage(Object , Object[] , Object[] ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)



    WHY OH WHY Do I get this error, when ADO.NET Data Services can serialize an Entity fine by going straight to Entity Framework, but when I am trying to do the right thing and abstract out EF, it can no longer seem to do it. Its the SAME object. Why is it getting caught on EntityState Enum? It obviously gets past it using EF as the provider? Is there something I can do to tell it to not utilize this field w/o going through the mass amounts of time to make DTOs, when my Entities are perfectly fine as DTOs? I do not want to include my business logic in EF through partial classes. My reasoning, when the next version comes out and supports POCO appropriately, I would like to move to it and not have to change an arm and leg to get working. I am trying to abstract EF from my business domain logic, so that I can minimize headache down the road.


    Help me please!

    Friday, August 15, 2008 7:59 PM

All replies


    From the stack trace you have provided, it appears that the 'T' in your DataService<T> class isn't an ObjectContext type. The presence of a 'ReflectionServiceProvider' type on the stack is the indicator.


    When it comes to figuring out what the structure of the types is, the data service has two choices: if the 'T' is an ObjectContext, then it can provide metadata about the type structures through CSDL. If this is not the case, it will use reflection to examine types and their properties, and you can customize the discovery process by using attributes (some I discuss at


    Given that you already have an Entity Framework-based model, the most straightforward approach would be to leverage the work put into creating the model and use the ObjectContext-derived type as the 'T' in your service.


    Please let me know if this poses a problem.


    (about the EntityState property in particular: IIRC, this is an enum, which aren't currently supported; you can 'shadow' this if you introduce a read/write calculated property of type string, for example)

    Saturday, August 16, 2008 6:28 PM
  • Thank you for your response Marcelo. However, I cannot really expose EF as the Provider, nor can I easily mark up a code generated property built into EF Entities.

    Here is the situation as best I can describe it:

    I am trying to abstract out Entity Framework by exposing to ADO.NET Dataservices my business layer objects (where all of my validation and most of my business layer will be), which will expose my Entities from EF (which are my DTO's in this instance). I have gone through great pain in marking up my Business Layer with IUpdateable and IExpandProvider, so that it can validate and use my domain logic against the services.

    I would rather not expose the Object Context, because it would bypass all of my validation logic (which it doesnt give me a warm fuzzy feeling pushing even more down into my EntityObjects - even if it would be in a partial class separated file, since that would essentially bloat my entities even more -- which would blow even more the idea of single responsibility), and I would hate the amount of work necessary to make my own DTO's and have to mimic my Entities already defined from Entity Framework (not to mention some shortcomings with projections in EF as compared to L2Sql with regards to Client vs Server projections -- i.e. you would have to bring down more from Sql Server to project into your custom objects).

    And since I am relying on the designer to work with my entities (since it doesnt support POCO yet, why put in the energy to make an IPOCO representation, since it will basically come out like the generated code at this point), I cannot markup the EntityState enum with a ADO.NET Dataservice Attribute to tell it to ignore it, since it isnt generated with a virtual (which means I have no way to expand on pre-built functionality in EF -- did I mention I cant wait till true POCO support is done).

    Essentially, I am caught between a rock and a hard place. I want to utilize EF and ADO.NET Data Sevices, because I believe in these projects, but at every step, with me trying to design out my abstractions, I get stopped by it working, because I am not doing it the easy, highly coupled way, of just linking everything together and calling it a day. I want to use these frameworks, in my layered architecture at their correct places.

    However, even though it works the default intended way (EF as the Provider to Data Services), when I try to extend them (in my layered architecture), they do not work. My main problem after 2 weeks of fighting with EF and ADO.NET DataServices to play nice in their sensible de-coupled layers, is that it cannot treat an Entity from EF the same way as if it would have in the default scenario
    (EF as the Provider to Data Services). I assume from your post the reason why it does work in the default scenario, is that it is able to read the CSDL, and bypass the enum problem, etc. But since it is now using reflection, it cannot. Is there anything I can do. Please help me, I do not want to have to tear out all the work I have put into trying to make this work, when I just followed what I was told I had to do to make this work: i.e. expand with IUpdateable, and IExpandProvider, and the fact that Entities works fine if you couple it to EF.

    Please, there has to be some way to accomplish what I am trying to do. I have fought tooth and nail to get everything to work down to the BO, and to get stuck on an Enum auto-generated by EF would really be frustrating. I know I can build DTO's, but that would be major work, and essentially, what would be the point of EF in that instance, since it would be nothing more than L2Sql or ADO.NET to just fill up my DTO's.

    What I am trying to accomplish:

    EF + Repository Object
    Business Layer
    B.Objects for each major Entity with Validation and Domain Logic (*made it fine to here with IUpdateable,etc*)
    Service Layer
    Ado.Net Data Service exposing the Entities as DTO's but from the B.O's logic, not EFs, so I have more control over what it does.
    Model Layer
    Handle making requests to my SOA Services
    Controller Layer
    View Layer with Javascript
    Sunday, August 17, 2008 4:10 AM

    The IgnoreProperties attribute as defined on can be used on the entity type classes rather than the properties, so you can use them on partial classes defined in a separate C# file. You'll also want to hide the EntityKey property, and possibly other infrastructure-supporting properties (sorry I don't have a build at hand to check this out for you).


    I think this should allow you to proceed with your layering, but please let me know if this isn't the case.

    Tuesday, August 19, 2008 6:56 AM
  • Corey I know that this is two years old but did you ever figure out the solution to your problem? I am facing a similar problem right now.


    [Edit] - I ended up going the POCO route:

    • Proposed as answer by DeviantSeev Thursday, October 28, 2010 3:34 PM
    Wednesday, October 27, 2010 6:22 PM