views:

122

answers:

1

My problem resembles this question but is not exactly the same: http://stackoverflow.com/questions/1460063/change-culture-when-deserializing-wcf-service

I have built a WCF (web) service running on Windows 7 (IIS 7.5) using VS 2008. One of the properties in my webservice is typed as a System.Double. When building my own client for testing the service, Visual Studio requiers my to write - for example - a number like 123.4 (using a dot as the decimal point). But when using WcfTestClient.exe to access the service and entering a number on the field (like 123.4, still using a dot) it gives me the message "123.4 the is not a valid value for this type". I should mention I live in Sweden and comma is the culture-specific decimal point symbol here.

If I instead use a comma (,) as the decimal point when using WcfTestClient, that is accepted. The problem is that when I debug my webservice code I can see that the comma gets removed by the serializing process somehow and the number has been changed to 1234. Not good.

In my dev environment I have both the service and client running on the same machine. The webservice is running under the NetworkService account which uses the same locale.

My question is: how do I in WCF make sure that whatever number that's supplied on this field/property to the webservice, if containing a comma the comma should NOT be stripped away?

I thought this was automatically handled in the framework. I don´t really care if the number is stored with a comma or a dot as long as the value stays the same.

I am using the DataContractSerializer and auto-implemented properties, like this: [DataMember] public double Price { get; set; }

I've also tested building a property using Convert.ToDouble(value, System.Globalization.CultureInfo.InvariantCulture) in the setter with no visible change in outcome in the WCF Service.

A: 

Can you tell if it is the wcf test client, or your web service that is messing up the serialization? Maybe try enabling full message logging in WCF and check the incoming message body to see if it contains "1234" or "123,4" or "123.4". Maybe (hopefully) its just a bug in the WCF test client.

Link to MSDN page to set up message logging: http://msdn.microsoft.com/en-us/library/ms730064.aspx And set:

logEntireMessage="true"
logMessagesAtServiceLevel="false" 
logMessagesAtTransportLevel="true"

I think that should give you a service log that has the raw incoming message. You might have to turn off transport level security (SSL) if you have it enabled.

rally25rs
I've tried message logging. The file in Trace Viewer only shows the encrypted messages. I tested using both Message and Transport security modes on the binding but the messages stays encrypted. If I try <security mode="None" /> the client hangs for some reason.
Cendion
I managed to get the messages stored in unencrypted form now. I can see that the value is stored with the decimal symbol removed <a:Price>1234</a:Price>.I don't belive that it is a bug in Wcf Test Client. I saw in this forum (the first answer) some explanation on the culture issue (not related to WCF): http://www.velocityreviews.com/forums/t302304-convert-to-double-is-country-depending.html
Cendion