WCF Data Services and EF POCOs that are in their own Assembly

I hit my head against a wall for a while today when I was trying to create a data service using my EF POCOs. I have my model & context in one assembly and my generated POCO entities in another.

When I ran the service (I had exposed all EntitySets for AllRead), I got the mysterious error:

The server encountered an error processing the request. See server logs for more details.

Even with config.UseVerboseErrors = true; in my service, the message did not change.

I finally saw the real problem first in Intellitrace (I’m using VS2010 and .NET 4.0) and then by setting the service behavior’s IncludeExceptionDetailInFaults to true.

This is what the detailed exception looks like:

The server encountered an error processing the request. The exception message is ‘Value cannot be null. Parameter name: key’. See server logs for more details. The exception stack trace is:

at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument) at System.Collections.Generic.Dictionary`2.FindEntry(TKey key) at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at System.Data.Services.Providers.ObjectContextServiceProvider.PopulateMetadata(IDictionary`2 knownTypes, IDictionary`2 childTypes, IDictionary`2 entitySets) at System.Data.Services.Providers.BaseServiceProvider.PopulateMetadata() at System.Data.Services.DataService`1.CreateProvider() at System.Data.Services.DataService`1.EnsureProviderAndConfigForRequest() at System.Data.Services.DataService`1.HandleRequest() 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.ProcessMessage41(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet

Key in here for me are “PopulateMetadata” and argument is null.

Looks like we can’t read the metadata, i.e. the CSDL, MSL and/or SSDL files. I’ve got he connection string in web.config so that ‘s not it.

With this info in hand, I found this forum post which clarified the issue: Fail to work with POCO ModelContainer which entities are located in

I neede to force the metadata to load into the application process. I have a handy trick for this which is simpler than the one suggested in the forum.

I blogged about it in 2008: Quick Trick for forcing MetadataWorkspace ItemCollections to load.

So, I added this override to the data service:

     protected override BAPOCOs CreateDataSource()
     {
       var context = new BAPOCOs();
       var tracestring = context.CreateQuery<Contact>("BAPOCOs.Contacts").ToTraceString();
       return context;
     }

Note that calling ToTraceString does not cause a command to be executed on the server.

And my service was back in working condition, however…

There is one thing I’m not happy with. I originally had a test in there to see if the metadata was already loaded. If so, then no need to call ToTraceString. The metadata is supposed to remain in teh app process so after the first hit, I should be skipping the ToTraceString code. However, it was being hit every time and if I forced it to skip, then I was back to the original error.

This seems like an expensive waste of resources and if that’s the case, I’m doing it on EVERY call, I’d rather use the more complex code which explicitly loads the MDW rather than my little trick which is not a big deal if I’m only doing it once. The upside is that this is essentially an Entity SQL query and by default ESQL queries are cached and do not need to be recompiled. So perhaps it’s not so bad. Either way, I’d like to get this solution to a more satisfactory state.

I have asked about this in the above mentioned forum thread.  And will add to this blog post when I get more info.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

7 thoughts on “WCF Data Services and EF POCOs that are in their own Assembly

  1. yes I discovered you are debigging blind until you turn on IncludeExceptionDetailInFaults in the config for the WCF.

    Even then as you are aware it can still be dificult at first to get it going! there are other config values to do with size of graphs and other timeout related config values.

  2. Julie,

    I have attempted to override GetDataSource() as you have outlined, but I still get the exception.

    I am using the bits from Visual Studio 2010 RC, has something changed?

  3. @brian…I’m pretty sure this was in RC. I’m not sure what to tell you. Maybe if you leave a comment on the above noted MSDN thread someone from MS might be able to help?

  4. Hi! I tried your trick with the VS2010 RTM code but I’m still getting the error. Any further ideas how to resolve this?

Leave a Reply to Alan Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.