WCF net.pipe aborts when receiving response - wcf

Question

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: Execute
(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.
Solution
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.

Answer 1

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.