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

Моя цель состоит в том, чтобы отправить ServiceType объекты по проводам через myInitializationData договора.

Я предотвращено украшения myInitializationData или ClientInitializationData классы с KnownType из ServiceType, потому что эти классы являются общими (связаны) с проектом Silverlight (ов). Поэтому, если я украшу любой из этих классов с помощью KnownType ServiceType, стороны 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)
• To: Выполнить (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 из ClientInitializationData DataContract, эта ошибка исчезнет. Поэтому я предполагаю, что это должна быть проблема с сериализацией re: интерфейс и KnownTypes, но WCF не требует каких-либо проблем с сериализацией в трассировке, и я не уверен, что в этом случае означает трассировка.

---

Решение

Это был не вопрос KnownTypes. Это было результатом того, что LazyLoading был спонтанно включен в контексте сущности, определяющем тип ServiceType.

Хотя не упоминается чрезмерное сообщение или размеры буфера, которые нарушаются в трассировке (на стороне клиента или на стороне сервера), я должен предположить, что включение LazyLoading в контексте EF заставило DataContractSerializer инициировать EF в выборку много записей, которые, в свою очередь, привели к массивному графику (попытка) на проводе. На стороне сервера была просто (и неоднозначно) ошибка канала во время записи сообщения.

Возврат LazyLoading к отключенному состоянию в контексте EF с тех пор решил эту проблему.

Answer 1

Это не было проблемой KnownTypes. Это было результатом того, что LazyLoading был спонтанно включен в контексте сущности, определяющем тип ServiceType.

Хотя не упоминается чрезмерное сообщение или размеры буфера, которые нарушаются в трассировке (на стороне клиента или на стороне сервера), я должен предположить, что включение LazyLoading в контексте EF заставило DataContractSerializer инициировать EF в выборку много записей, что, в свою очередь, привело к тому, что на проводнике был сделан массивный график (попытка). На стороне сервера была просто (и неоднозначно) ошибка канала во время записи сообщения.

Возврат LazyLoading к отключенному состоянию в контексте EF с тех пор решил эту проблему.