WCF net.pipe aborts when receiving response

This has been resolved

This is a contract I'm unable to get from a service call:

[DataContract]
public class myInitializationData : ClientInitializationData
{
    [DataMember]
    public Dictionary<string, string> CultureNameLookup { get; set; }
}

Here's it's base type,

[DataContract]
public class ClientInitializationData
{
    [DataMember]
    public List<IServiceType> ServiceTypes { get; set; }
}

IServiceType is an interface. I realize I cannot send an interface across the wire. There is an EntityFramework entity, ServiceType, implementing the IServiceType interface:

public partial class ServiceType : IServiceType
{
    //...
}

My goal is to send ServiceType entities across the wire via the myInitializationData contract.

I am prevented from decorating the myInitializationData or ClientInitializationData classes with a KnownType of ServiceType, because these classes are shared (linked) to Silverlight project(s). So if I decorate either of these classes with a KnownType of ServiceType, the Silverlight side(s) will fail to compile.

Instead of decorating the classes directly, I decorated the service contract with with a ServiceKnownType of ServiceType:

[ServiceContract]
[ServiceKnownType(typeof(ServiceType))]
public interface IService
{
    [OperationContract]
    myInitializationData InitializeClient();
}

Should this work?

When calling IService.InitializeClient, I receive the following error on the client:

There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).

I have enabled trace debugging but found no messages regarding failure to serialize in the trace for either client or server.

Server trace:

• Receives a message ever a channel (Action: http://tempuri.org/IService/InitializeClient)
• To: E开发者_如何学Pythonxecute (IService.InitializeClient)
• From: Execute (IService.InitializeClient)
• Sends a message over a channel (Action: http://tempuri.org/IService/InitializeClientResponse)
• Warning Faulted System.ServiceModel.Channels.ServerSessionPreambleConnectionReader+ServerFramingDuplexSessionChannel
• Warning Faulted System.ServiceModel.Channels.ServiceChannel
• Replying to an operation threw an exception (The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.)

Client trace:

• Sends a message over a channel (Action: http://tempuri.org/IService/InitializeClient)
• Throwing an Exception (There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).)

If I opt the ServiceTypes property out of the ClientInitializationData DataContract, this error goes away. So I assume this must be a serialization issue re: the interface and KnownTypes, but WCF isn't claiming to have any serialization issues in the trace, and I'm not sure what the trace means in this case.

This was not a KnownTypes issue. It was the result of LazyLoading having been spontaneously enabled on the entity context defining the ServiceType type.

Although there is no mention of excessive message or a buffer sizes being violated in the trace (on either the client or server sides), I must assume the enabling of LazyLoading on the EF context caused the DataContractSerializer to trigger EF into fetching a lot of records, which in turn resulted in a massive graph being (attempted) on the wire. The server side was simply (and ambiguously) faulting the channel during the message write.

Returning LazyLoading to a disabled state on the EF context has since solved this problem.

This was not a KnownTypes issue. It was the result of LazyLoading having been spontaneously enabled on the entity context defining the ServiceType type.

Although there is no mention of excessive message or a buffer sizes being violated in the trace (on either the client or server sides), I must assume the enabling of LazyLoading on the EF context caused the DataContractSerializer to trigger EF into fetching a lot of records, which in turn resulted in a massive graph being (attempted) on the wire. The server side was simply (and ambiguously) faulting the channel during the message write.

Returning LazyLoading to a disabled state on the EF context has since solved this problem.