WCF net.pipe收到响应时中止

Question

这个已经解决了

---

这是我无法通过服务电话获得的合同：

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

这是基本类型

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

IServiceType是一个接口。 我意识到我无法通过电线发送接口。 有一个EntityFramework实体ServiceType ，实现了IServiceType接口：

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

我的目标是通过myInitializationData合同跨线发送ServiceType实体。

我被阻止用ServiceType的KnownType装饰myInitializationData或ClientInitializationData类，因为这些类被共享（链接）到Silverlight项目。 因此，如果用ServiceType的KnownType装饰这些类中的任何一个，Silverlight端将无法编译。

我没有直接修饰类，而是使用ServiceType的ServiceKnownType修饰了服务协定：

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

应该行吗？

调用IService.InitializeClient ，我在客户端上收到以下错误：

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

我已启用跟踪调试，但没有发现有关客户端或服务器跟踪中无法序列化的消息。

服务器跟踪：

• 通过频道接收消息（ 操作： http : //tempuri.org/IService/InitializeClient ）
• 若要：执行（ IService.InitializeClient ）
• 从：执行（ IService.InitializeClient ）
• 通过通道发送消息（ 操作： http : //tempuri.org/IService/InitializeClientResponse ）
• 警告错误的System.ServiceModel.Channels.ServerSessionPreambleConnectionReader + ServerFramingDuplexSessionChannel
• 警告错误的System.ServiceModel.Channels.ServiceChannel
• 对操作的答复引发了一个异常（ ObjectContext实例已被处置，不能再用于需要连接的操作。 ）

客户跟踪：

• 通过通道发送消息（ 操作： http : //tempuri.org/IService/InitializeClient ）
• 引发异常（ 从管道读取错误：管道已结束。（109，0x6d）。 ）

如果我从ClientInitializationData DataContract中选择ServiceTypes属性，则该错误消失了。 因此，我认为这一定是序列化问题，即接口和KnownTypes，但是WCF并未声称在跟踪中存在任何序列化问题，并且我不确定在这种情况下跟踪的含义。

---

解

这不是KnownTypes问题。 这是在定义ServiceType类型的实体上下文上自发启用了LazyLoading的结果。

尽管没有提到过多的消息或在跟踪中（在客户端或服务器端）违反了缓冲区大小，但我必须假定在EF上下文中启用LazyLoading导致DataContractSerializer触发EF提取大量记录，进而导致在线上尝试了一个庞大的图形。 在消息写入过程中，服务器端只是（模棱两可）地使通道出错。

此后，在EF上下文中将LazyLoading返回禁用状态已经解决了此问题。

Answer 1

这不是KnownTypes问题。 这是在定义ServiceType类型的实体上下文上自发启用了LazyLoading的结果。

尽管没有提到过多的消息或在跟踪中（在客户端或服务器端）违反了缓冲区大小，但我必须假定在EF上下文中启用LazyLoading导致DataContractSerializer触发EF提取大量记录，进而导致在线上尝试了一个庞大的图形。 在消息写入过程中，服务器端只是（模棱两可）地使通道出错。

此后，在EF上下文中将LazyLoading返回禁用状态已经解决了此问题。