Changer la culture quand désérialisation service WCF

Question

J'utilise C # pour lire les données à partir d'un Java webservice.

J'ai créé une référence de service dans VS2008 au serveur, et peut appeler une méthode qui est là. Cependant, quelques-uns des champs retournés sont de type décimal, et que le proxy WCF généré automatiquement obtient XML arrière, il échoue avec une CommunicationException disant:

"Error in deserializing body of reply message for operation 'getOpenReceivables'."
"There is an error in XML document (1, 941)."
"Input string was not in a correct format."

[Modifier] Voici une stacktrace complète:

at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)   
at System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider)
at System.Xml.XmlConvert.ToDecimal(String s)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderExecutePortType.Read2_XXNG_OPEN_RECEIVABLES(Boolean isNullable, Boolean checkType)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderExecutePortType.Read3_Item()  
at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer.Deserialize(XmlSerializationReader reader)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)

Je peux voir que le nombre décimal retourné est formaté avec une ponctuation comme la décimale. Pour des fins de test j'ai essayé un Decimal.Parse ( « 123,99 ») et a obtenu la même erreur. En définissant un

System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");

avant mon TestCode pour Decimal.Parse ( "123,99") j'obtenir que le travail.

Cependant, le réglage de la CurrentCulture avant d'appeler la méthode WCFService ne fait aucune différence.

Y a-t-il des moyens que je peux obtenir mon WCFService objet proxy pour comprendre que le retour XML est dans un autre cultureformat?

Answer 1

Avez-vous essayé d'utiliser un IClientMessageFormatter .DeserializeReply () mise en œuvre? WCF est farcie aux branchies avec points d'extension, il est souvent difficile de savoir lequel choisir, mais DeserializeReply ressemble l'outil pour ce travail.

Jetez un oeil à

Answer 2

Vous pouvez joindre un initialiseur de culture à un comportement que vous ajoutez ensuite à un point de terminaison. Cela fixerait la culture sur le fil désérialisation la réponse, le champ doit donc être désérialisée correctement.

Pour un exemple de code de cela, un regard sur ce lien:

http : //blogs.msdn.com/drnick/archive/2008/02/26/using-call-context-initializers-for-culture.aspx

Je serais très surpris si la culture est vraiment le problème. spécifications XML indique que les décimales utilisent le point comme séparateur, et (de) sérialiseur sait. Pouvez-vous retracer le message et voir ce qui est dans la position à 941? (Soit dit en passant: J'aime SoapUI pour de telles choses, en plus de tracer WCF) Quand il s'agit de décimales, peut-être la précision différente pourrait être un problème: peut-être le service Java met plus 666.666.666.666 avant le 7 en cas de deux tiers de fuite que la décimale .net peut gérer

Et il y a une deuxième option: la décimale est pas vraiment une décimale (encore une fois: tracer le message serait très enlighting). J'ai trouvé ce lien qui se lamente un peu sur les services amazon, qui pourrait mettre l'unité dans la valeur décimale (par la voie: WTF !?). Cependant, il y a une belle description sur la façon d'interagir avec le message brut avant de passer à la désérialisation en utilisant l'interface IClientMessageInspector. Si un tel cas étrange est votre problème, vous pouvez soit forcer le fournisseur de services de se conformer à son propre contrat ou faire une telle affaire (si le fournisseur est en dehors de votre sphère de contrôle et dit « ceci est par la conception »).

Answer 3

Vous pouvez joindre un initialiseur de culture à un comportement que vous ajoutez ensuite à un point de terminaison. Cela fixerait la culture sur le fil désérialisation la réponse, le champ doit donc être désérialisée correctement.

Pour un exemple de code de cela, un regard sur ce lien:

http : //blogs.msdn.com/drnick/archive/2008/02/26/using-call-context-initializers-for-culture.aspx

Answer 4

Je serais très surpris si la culture est vraiment le problème. spécifications XML indique que les décimales utilisent le point comme séparateur, et (de) sérialiseur sait. Pouvez-vous retracer le message et voir ce qui est dans la position à 941? (Soit dit en passant: J'aime SoapUI pour de telles choses, en plus de tracer WCF) Quand il s'agit de décimales, peut-être la précision différente pourrait être un problème: peut-être le service Java met plus 666.666.666.666 avant le 7 en cas de deux tiers de fuite que la décimale .net peut gérer

Answer 5

Et il y a une deuxième option: la décimale est pas vraiment une décimale (encore une fois: tracer le message serait très enlighting). J'ai trouvé ce lien qui se lamente un peu sur les services amazon, qui pourrait mettre l'unité dans la valeur décimale (par la voie: WTF !?). Cependant, il y a une belle description sur la façon d'interagir avec le message brut avant de passer à la désérialisation en utilisant l'interface IClientMessageInspector. Si un tel cas étrange est votre problème, vous pouvez soit forcer le fournisseur de services de se conformer à son propre contrat ou faire une telle affaire (si le fournisseur est en dehors de votre sphère de contrôle et dit « ceci est par la conception »).