I\'m using WCF Dataservices CTP2 with Entity Framework 4.1. Now then I\'m trying to get any data through my datacontext I get this exception:
System.R
Just came across the same error message and fixed it on my end. Turns out I was mixing up assemblies between my service and client. One was using Microsoft.Data.Services, the other was using System.Data.Services.
Okay, I think this is a bug of a new WCF CTP2. Then I added back the System.Data.Services 4.0.0 reference I got the correct Namespaces in my data service. But then I use v4.99.2.0 I get the wrong namespace in my ds.
Did you try implementing delegates for DataServiceContext.ResolveName
and DataServiceContext.ResolveType
? Those 2 delegates, if provided, can be used to fixup the mapping between odata namespaces + names, and the types that are serialized and deserialized on the client.
Here is a simple example:
internal class CustomDataServiceContext : DataServiceContext
{
public CustomDataServiceContext(Uri serviceRoot)
: base(serviceRoot, DataServiceProtocolVersion.V3)
{
this.ResolveName = ResolveNameFromType;
this.ResolveType = ResolveTypeFromName;
}
protected string ResolveNameFromType(Type clientType)
{
if (clientType.Namespace.Equals("ODataClient.MSProducts", StringComparison.Ordinal))
{
return string.Concat("ODataService.Models.", clientType.Name);
}
return clientType.FullName;
}
protected Type ResolveTypeFromName(string typeName)
{
if (typeName.StartsWith("ODataService.Models", StringComparison.Ordinal))
{
return this.GetType().Assembly.GetType(string.Concat("ODataClient.MSProducts", typeName.Substring(19)), false);
}
return null;
}
}
I had to do something like this (but I made it flexible instead of hard-coded) in order to make my entity classes work in the WCF Data Services client;
But even after doing this, I had this error:
System.InvalidOperationException : There is a type mismatch between the client and the service. Type WorkItem' is not an entity type, but the type in the response payload represents an entity type. Please ensure that types defined on the client match the data model of the service, or update the service reference on the client.
I found two fixes that worked for this:
[DataServiceKey("Id")]
attribute to your entity class.
orID
I figured out #2 the hard way - looking at the decompiled IL (this is for WCF Data Services 5.2.0). After reviewing ClientEdmModel
and ClientTypeUtil
, I came across this method in ClientTypeUtil
:
private static ClientTypeUtil.KeyKind IsKeyProperty(PropertyInfo propertyInfo, DataServiceKeyAttribute dataServiceKeyAttribute)
{
string name1 = propertyInfo.Name;
ClientTypeUtil.KeyKind keyKind = ClientTypeUtil.KeyKind.NotKey;
if (dataServiceKeyAttribute != null && dataServiceKeyAttribute.KeyNames.Contains(name1))
keyKind = ClientTypeUtil.KeyKind.AttributedKey;
else if (name1.EndsWith("ID", StringComparison.Ordinal))
{
string name2 = propertyInfo.DeclaringType.Name;
if (name1.Length == name2.Length + 2 && name1.StartsWith(name2, StringComparison.Ordinal))
keyKind = ClientTypeUtil.KeyKind.TypeNameId;
else if (2 == name1.Length)
keyKind = ClientTypeUtil.KeyKind.Id;
}
return keyKind;
}
It's that name1.EndsWith("ID"
that is the key when using your POCOs on the client side of WCF Data Services.
Hope that helps.
I've had a similar problem, dont know whether or not it will fix yours.
What I had to do was to override the "CreateDataSource" method and turn off proxy creation in the svc.cs file.
Here's the code:
protected override DataServiceContext CreateDataSource()
{
var db = base.CreateDataSource();
db.Configuration.ProxyCreationEnabled = false;
return db;
}
I'd say that you're referencing another implementation of the Segmentation
class than the service's. Check out the namespace of Segmentation
in your CreateQuery<>()
call and the namespace of the Segmentation
class in your service.