Les valeurs Null pour les propriétés de l'objet désérialisé par la WCF

J'ai un service web WCF qui utilisé pour fonctionner correctement. Quelque part en bas de la ligne, il s'est arrêté et je ne peux pas dire pourquoi. Le code et l'interface n'a jamais changé ni ne le web.config (au moins pas par rapport à la section des services web). J'ai une classe:

[DataContract]
public class QuizServiceArgs
{
    [DataMember(IsRequired = true, Order = 1)] 
    public int Category1 { get; set; }

    [DataMember(IsRequired = true, Order = 2)] 
    public int Category2 { get; set; }

    [DataMember(IsRequired = true, Order = 3)] 
    public int Category3 { get; set; }

    [DataMember(IsRequired = true, Order = 4)] 
    public int Category4 { get; set; }
}

Et l'interface du service est simple:

public interface IQuizService
{
    [OperationContract]
    [WebInvoke(Method = "POST",
       BodyStyle = WebMessageBodyStyle.WrappedRequest,
       ResponseFormat = WebMessageFormat.Json)]
    ServiceResult Save(QuizServiceArgs answers, string strvalue, int intvalue);
}

La seconde deux params strvalue et intvalue ont été ajoutés uniquement pour le dépannage pour voir si ceux qui ont arriver désérialisé-et ils le sont. Quand j'appuie sur le service, j'obtiens un message d'erreur disant que je suis absent la Category1 paramètre à partir de la demande, mais comme vous pouvez le voir, cette Violoniste de capture d'écran, les valeurs sont là.

Les valeurs Null pour les propriétés de l'objet désérialisé par la WCF

Je peux obtenir des valeurs primitives pour passer en mais les objets semblent tous être instancié avec la valeur null ou les valeurs par défaut. Ce que je fais mal?

Mise à JOUR

Je n'ai jamais vraiment eu ma réponse à la question qui suce, mais Sixto a suggéré que je fais passer mon sérialisation JSON. JSON était à l'origine de la conception, mais suis mis son veto quand j'ai eu des ennuis avec elle. Après, j'ai réussi à passer de retour à JSON, tout était la sérialisation et la désérialisation correctement. Maintenant, je suis juste en attente pour cet de faire une pause pour aucune explication afin que je puisse revenir à XML....

par ailleurs, j'ai rogné certains en-têtes de la fiddler demande que j'ai considéré comme du bruit. ne vous inquiétez pas si il ny a pas de Contenu, la longueur de l'attribut dans le pic, il y en avait un dans la demande 🙂
Avez-vous changé l'Ordre de propriété sur les données, qualités des membres? Ou tous les espaces de noms? Ou de supprimer tout les membres?
Les attributs sont du même ordre dans le POSTE qu'ils sont spécifiés dans le code. Je n'ai pas tous les espaces de noms - je l'ai gardé vide dans d'autres projets et il a travaillé très bien. Je n'ai pas enlever tous les membres. C'est littéralement la totalité de mon QuizServiceArgs classe.

OriginalL'auteur Jeff | 2011-05-02

  1. 5

    DataMember IsRequired attribut indique la WCF deserializer attendues d'un élément dans le message XML avec ce nom (à moins qu'il ne l'est pour le savon de la désérialisation). Il semble que le code client qui est la génération de la demande de message n'est plus de l'envoi de toutes les Catégorie... éléments. Cela ne signifie pas que vous ne pouvez pas envoyer une valeur null pour un DataMember marqué IsRequired, il veut simplement dire que l'élément doit exister dans le message.

    Mise à JOUR: en regardant le XML de plus près, ne devrait-il pas être un QuizServiceArgs élément dans le fichier XML?

    Je ne suis pas vraiment au point du code de client encore. J'ai utilisé Fiddler manuellement craft ma demande. Dans la capture d'écran, vous pouvez voir que le CategoryX valeurs sont dans le schéma XML qui est envoyé au serveur. Je comprends que le serveur pense que je ne suis pas l'envoi de ces propriétés. Je ne sais pas pourquoi il pense que.
    Je ne suis pas trop familier avec la façon dont le XML devrait ressembler pour WebInvoke mais le message d'erreur dit que le deserializer n'est pas de trouver la Catégorie... éléments avant qu'elle ne touche les réponses de l'élément de balise de fin.
    En fait, je pense que le principal problème est que vous définissez l'WebInvoke formateur en json au lieu de XML 🙂
    La réponse JSON. La demande est par défaut en XML. J'aurais préféré la demande et de la réponse à la fois être JSON mais j'ai eu de la difficulté à obtenir la demande de travail pour JSON et juste laissé au format XML pour des raisons de simplicité. C'est peut-être temps de revoir le JSON demande.
    Vous navez pas directement répondu à ma question, mais j'ai tout de travailler en commutation, tout en JSON au lieu de mélanger JSON et XML. J'ai eu toutes les requêtes AJAX en passant par mon wrapper ajax fonction de la modification de tout sur l'application a été facile. Merci.

    OriginalL'auteur Sixto Saez

  2. 8

    Vous disposez d'un espace de noms en question. Par défaut, lorsque vous créez une interface pour le servicecontract, il l'attribue à un espace de noms. Espace de noms est comme portée par le SAVON d'éléments xml, et si ça ne tombe pas sous le même champ d'application, elle pense qu'il n'existe pas. Les Chances sont le code des postes stoppped fournir de l'espace de noms(?). Vous devez vous référer par elle lors de l'affichage de XML - mais je ne suis pas entièrement sûr de ce qu'il attribue(quelque chose de spécifique au serveur), de sorte qu'il est de bonne pratique de toujours définir un espace de noms, comme suit:

    
[ServiceContract(Namespace = "your namespace")]
public interface IQuizService 
{     
     [OperationContract]     
     [WebInvoke(Method = "POST",        
            BodyStyle = WebMessageBodyStyle.WrappedRequest,        
            ResponseFormat = WebMessageFormat.Json)]     
            ServiceResult Save(QuizServiceArgs answers, string strvalue, 
                int intvalue); 
}

    Et puis les messages doivent avoir de l'espace de noms dans la requête SOAP.

    
<Save xmlns="your namespace">.....</Save>

    L'espace de noms doit également correspondre à votre déclaration de service web.config.

    Également besoin dans le datacontract

    [DataContract(Namespace = "your namespace")]

    J'ai ajouté un espace de noms pour les trois lieux: ServiceContract sur l'interface, le nœud racine de la demande et le point de terminaison bindingNamespace dans le web.config. Même réponse. J'ai utilisé de la WCF sans l'espace de noms avant sans problème donc je ne suis pas terriblement surpris de voir que j'ai encore le problème.
    Je suis encore assez certains de ses un espace de noms en question. Comme je l'ai mentionné, il y a un par défaut assigné, qui, si elle correspond devrait fonctionner correctement. Oh, et vous avez aussi besoin dans le datacontract - [DataContract(Namespace = "votre espace de noms")]. Ils ont tous la queue pour le travail...
    Vous avez juste m'a sauvé beaucoup de temps! Une prime de 300 sur la façon de vous M. R.

    OriginalL'auteur M.R.