2010-11-10 25 views
0

Cela a été résoluWCF net.pipe avorte lors de la réception réponse


Ce contrat, je suis incapable d'obtenir à partir d'un appel de service:

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

Voici c'est le type de base ,

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

IServiceType est une interface. Je réalise que je ne peux pas envoyer une interface à travers le fil. Il y a une entité EntityFramework, ServiceType, la mise en œuvre de l'interface IServiceType:

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

Mon but est d'envoyer ServiceType entités à travers le fil via le contrat myInitializationData.

Je suis empêché de décorer les classes myInitializationData ou ClientInitializationData avec un type connu de ServiceType, car ces classes sont partagées (liées) au (x) projet (s) Silverlight. Donc, si je décore l'une de ces classes avec un KnownType de ServiceType, le (s) côté (s) de Silverlight ne pourront pas être compilés.

Au lieu de décorer les classes directement, je décoré le contrat de service avec un ServiceKnownType de ServiceType:

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

Si ce travail?

Lorsque vous appelez IService.InitializeClient, je reçois l'erreur suivante sur le client:

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

J'ai activé le débogage de trace mais n'a trouvé aucun message concernant l'échec de sérialisation dans la trace pour client ou serveur.

trace du serveur:

  • reçoit un message jamais un canal (Action: http://tempuri.org/IService/InitializeClient)
  • : exécuter (IService.InitializeClient)
  • De: Exécuter (IService.InitializeClient)
  • Envoie un message sur un canal (Action: http://tempuri.org/IService/InitializeClientResponse)
  • Avertissement Faulted System.ServiceModel.Channels.ServerSessionPreambleConnectionReader + ServerFramingDuplexSessionChannel
  • Avertissement Faulted System.ServiceModel.Channels.ServiceChannel
  • En réponse à une opération a lancé une exception (L'instance ObjectContext a été supprimée et ne peut plus être utilisée pour les opérations nécessitant une connexion.)

Client trace:

Si j'opte la propriété ServiceTypes sur le DataContract ClientInitializationData, cette erreur disparaît. Donc je suppose que cela doit être un problème de sérialisation re: l'interface et KnownTypes, mais WCF ne prétend pas avoir de problèmes de sérialisation dans la trace, et je ne suis pas sûr de ce que la trace signifie dans ce cas.


Solution

Ce ne fut pas un problème KnownTypes. C'est le résultat de l'activation spontanée de LazyLoading sur le contexte d'entité définissant le type ServiceType. Bien qu'il n'y ait aucune mention d'un message excessif ou d'une taille de buffer violée dans la trace (côté client ou côté serveur), je dois supposer que l'activation de LazyLoading sur le contexte EF a provoqué le déclenchement de EF par le DataContractSerializer. beaucoup de d'enregistrements, ce qui à son tour a abouti à un graphique massif (tenté) sur le fil. Le côté serveur était simplement (et de manière ambiguë) en défaut sur le canal pendant l'écriture du message.

Le fait de retourner LazyLoading à un état désactivé sur le contexte EF a depuis résolu ce problème.

Répondre

1

Ce n'était pas un problème KnownTypes. C'est le résultat de l'activation spontanée de LazyLoading sur le contexte d'entité définissant le type ServiceType. Bien qu'il n'y ait aucune mention d'un message excessif ou d'une taille de buffer violée dans la trace (côté client ou côté serveur), je dois supposer que l'activation de LazyLoading sur le contexte EF a provoqué le déclenchement de EF par le DataContractSerializer. beaucoup d'enregistrements, qui à leur tour ont abouti à un graphique massif étant (tenté) sur le fil. Le côté serveur était simplement (et de manière ambiguë) en défaut sur le canal pendant l'écriture du message.

Le fait de retourner LazyLoading à un état désactivé sur le contexte EF a depuis résolu ce problème.