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
{
    //...
}

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

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

我没有直接装饰类，而是用ServiceKnownType ServiceType修饰了服务合同：

[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 ）
警告 Faulted System.ServiceModel.Channels.ServerSessionPreambleConnectionReader + ServerFramingDuplexSessionChannel
警告 Faulted System.ServiceModel.Channels.ServiceChannel
回复某项操作引发了异常（ ObjectContext实例已被释放，不能再用于需要连接的操作。）

客户跟踪：

通过频道发送消息（行动：http://tempuri.org/IService/InitializeClient ）
抛出异常（从管道读取错误：管道已经结束。（109,0x6d）。）

如果我从ServiceTypes DataContract中选择ClientInitializationData属性，则此错误消失。所以我认为这必须是一个序列化问题：接口和KnownTypes，但WCF并没有声称在跟踪中有任何序列化问题，我不确定跟踪在这种情况下意味着什么。

<小时/> 解决方案

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

虽然在跟踪中没有提到过多的消息或缓冲区大小（在客户端或服务器端），但我必须假设在EF上下文中启用LazyLoading导致DataContractSerializer触发EF获取<强大>很多的记录，这反过来导致在线上（尝试）大量图表。服务器端在消息写入期间简单地（并且模糊地）故障通道。

在EF上下文中将LazyLoading返回到禁用状态已经解决了这个问题。

Answer 1

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

虽然跟踪中没有提到过多的消息或缓冲区大小（在客户端或服务器端），但我必须假设在EF上下文中启用LazyLoading导致DataContractSerializer触发EF获取许多记录，这反过来导致在线上（尝试）大量图表。服务器端在消息写入期间简单地（并且模糊地）故障通道。

在EF上下文中将LazyLoading返回到禁用状态已经解决了这个问题。

WCF net.pipe在接收响应时中止

1 个答案: