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 返回到禁用状态已经解决了这个问题。