2009-07-16 4 views
1

Chaque fois que mon pool d'applications hôte WCF démarre, le client qui lui envoie le premier appel WCF lève toujours "System.Xml.XmlException: il y a éléments racines multiples "Tous les appels suivants fonctionnent parfaitement.Première demande WCF, le client lève systématiquement System.Xml.XmlException: Il y a plusieurs éléments racine

Cette exception se produit du côté client/client de la requête WCF. J'ai testé cela pour un client WCF complet et un client Silverlight. Il utilise basicHttpBinding, pas de sécurité, et aspnetCompatabilityMode = true

Ce ne serait pas un gros problème si le pool d'applications restait actif, mais avec le manque d'activité, il s'éteint et l'erreur se produit à nouveau quand il redémarre .

Je dois également mentionner que le pool d'applications commence parfois à partir d'une requête non-WCF vers une autre page. Mais encore la première fois que WCF est appelé, il lance toujours cette exception du côté client.

Quelqu'un a-t-il déjà vu ça? Je peux fournir plus de détails si nécessaire.

Merci

+0

Je doute: http://www.bing.com/search?q=XmlException+%22multiple+root+elements%22+wcf&go=&form=QBRE&qs=n –

Répondre

3

D'accord, après avoir recherché ces options, j'ai trouvé ce qui a causé le problème. En fin de compte, l'héritage et les deux attributs, sérialisable et DataContrat, dans les données échangées n'ont pas fait de différence en désérialisant la réponse.

La vraie viande de la question était dans ma configuration. Plus tôt, je jouais avec des messages de streaming. J'ai laissé mon serveur transferMode réglé sur Streaming et mon client a été mis en Buffered. En Silverlight, c'est ma seule option. Le problème de sérialisation s'est donc produit parce que le message était fragmenté. Je l'ai remarqué après avoir suivi quelques appels.

Difficulté facile de peasy. Basculer transferMode sur Buffered. Je vais configurer un point de terminaison distinct pour le streaming et jouer avec cette fois-ci. Je n'ai pas besoin de diffuser les services CRUD.

Merci pour les commentaires de tous.

-Nathan

+0

Résolu mon problème !! merci beaucoup –

0

Il me semble un problème de sérialisation. Je voudrais étudier comment vous construisez vos DataContracts - vous utilisez DataContracts et non les attributs de sérialisation XML, non?

Edit: Sur la base de nos commentaires, je vais donner une recommandation pour votre refactoring:

[DataContract] 
public class ImageEffectExcludeParamRequest 
{ 
    [DataMember] 
    public string ImageID { get; set; } 

    [DataMember] 
    public int EffectID { get; set; } 

    [DataMember] 
    public ResponseInfo AdditionalInfo { get; set; } 
} 


[DataContract] 
public class ResponseInfo 
{ 
    [DataMember] 
    public Enums.ServiceResponse.Status Status { get; set; } 

    [DataMember] 
    public string Message { get; set; } 
} 

composition à l'aide plutôt que l'héritage devrait résoudre votre problème.

+0

droit, ils sont toutes les classes simples avec DataContract, attributs DataMember uniquement. Hmm ... certaines opérations ont des paramètres qui incluent des entités avec Serializable et DataContract pour d'autres raisons. Celui que j'ai testé ne l'est pas. La valeur de réponse est un objet hérité. \t [DataContract] \t public class ImageEffectExcludeParamRequest: RequestBase \t { \t \t [DataMember] \t \t chaîne publique ImageID {get; ensemble; } \t \t [DataMember] \t \t public int EffectID {get; ensemble; }} \t – Nathan

+0

[DataContract] \t public abstract class ResponseBase \t { \t \t [DataMember] \t \t publique Statut Enums.ServiceResponse.Status {get; ensemble; } \t \t [DataMember] \t \t public string Message {get; ensemble; } \t \t ResponseBase publique() \t \t { \t \t \t this.Status = Status.NotSet; \t \t \t this.Message = null; \t \t} \t} – Nathan

+0

Je voudrais refactoriser; ne vous embêtez pas avec ResponseBase pour vos contrats de données. Au lieu de cela, dupliquez ce que vous devez ou encapsuler l'information dans un champ séparé. – Randolpho

Questions connexes