Comment empêcher la génération de propriétés "Spécifiées" dans les clients WCF?

Question

J'ai deux services WCF .NET 3.5 construits avec VS2008.

J'ai deux clients WCF dans Silverlight pour consommer ces services. Les clients sont générés avec le 'Ajouter une référence de service'. J'utilise Silverlight 4.

Un des proxies est généré avec Specified pour chaque propriété. Ceci est une classe 'message-in' pour ma méthode de service:

// properties are generated for each of these fields 
    private long customerProfileIdField;   
    private bool customerProfileIdFieldSpecified;   
    private bool testEnvField;   
    private bool testEnvFieldSpecified; 

Maintenant, mon autre service (toujours avec un client Silverlight) ne génère pas Specified propriétés.

Maintenant je ne me soucie pas de 'principes de bonne SOA'. Je veux juste me débarrasser de ces foutues propriétés parce que dans le contexte de ce que je fais, je les déteste absolument.

Il doit y avoir une différence entre les deux services - mais je ne veux pas les déchirer complètement pour découvrir la différence.

Un similar question avant avait la réponse 'you cant do it' - ce qui n'est certainement pas vrai parce que je l'ai - je ne sais pas ce que j'ai fait différemment. Editer: Je suis maintenant dans une situation où je régénère mon proxy Silverlight 4 à mon service 3.5 WCF (tous sur la même machine localhost) que parfois j'obtiens des propriétés 'Spécifiées' et parfois je ne le fais pas. Je ne pense plus (comme je le soupçonnais à l'origine) que cela est uniquement dû à une configuration de noeud final ou à un niveau de service [attribut]. Il y a certains déclencheurs dans le message lui-même qui provoquent la génération (ou non) de Spécifié. Il peut y avoir de nombreux facteurs en jeu ou cela peut être quelque chose de très simple.

Answer 1

essayer dans votre service WCF où la propriété est déclarée

[DataMember(IsRequired=true)] 
public bool testEnvField { get; set; } 

IsRequired=true niera la nécessité de la propriété testEnvFieldSpecified

Answer 2

OK, je l'ai trouvé une chose jusqu'à présent qui causera Specified propriétés à être généré:

• La présence d'un XTypedElement dans le message.

Ils sont utilisés par Linq2XSD. Je retournais un élément d'un modèle Linq2XSD.

Cela a déclenché Specified propriétés à générer tout dans toutes mes classes:

public XTypedElement Foo { get; set; } 

Cependant, cela n'a pas:

public XElement Foo { get; set; } 

Toujours curieux de savoir pourquoi il en est, et s'il y a des d'autres choses qui déclenchent cela.

Answer 3

Ces propriétés supplémentaires spécifiées sont générées pour les types de valeur spécifiés comme facultatifs dans le contrat ou le balisage d'attribut.Comme les types de valeurs ont une valeur par défaut, les indicateurs supplémentaires Specified sont ajoutés pour ces propriétés, afin de permettre au client (et au serveur) de faire la distinction entre quelque chose explicitement non spécifié ou explicitement spécifié - qui peut être défini sur valeur par défaut. Sans cela, les entiers finiraient toujours par être 0 (et étant sérialisés) même si vous ne les avez pas définis (à cause du mappage vers int) dans votre code client. Donc, lorsque vous le faites, vous devez également vous assurer que vous avez défini l'indicateur Specified sur true, sinon ces propriétés ne seront pas sérialisées. Par conséquent, pour éviter que ces indicateurs soient générés pour les types de valeur, vous devez modifier le contrat pour rendre ces propriétés de type valeur obligatoires, et non facultatives.

Espérons que cela a du sens.

Answer 4

NOTE: Je réalise que c'est une vieille question. J'ajoute ceci ici parce que cette question apparaît comme un résultat supérieur sur Google, et c'est l'information utile pour qui vient chercher.

Essayez d'ajouter cette ligne dans votre déclaration de contrat d'exploitation:
[XmlSerializerFormat]

Il devrait ressembler à ceci:

namespace WebServiceContract 
{ 
    [ServiceContract(Namespace = "http://namespace")] 
    [XmlSerializerFormat] //This line here will cause it to serialize the "optional" parameters correctly, and not generate the extra 
    interface InterfaceName 
    { 
     /*...Your web service stuff here...*/ 
    } 
}