views:

1374

answers:

3

I have a WCF service running that needs to parse some data. It turns out that data (points, sizes) gets converted differently in different CultureInfo's and the parsing is spread out in a lot of classes and methods. Since all the parsing is done without passing any CultureInfo the success of the parsing is dependant of the threads culture.

Since there is no programmatic setting of CultureInfo the service picks the current cultureinfo off the machine somehow. I have no idea where it gets this, since changes to the Regional and Language Options doesn't seem to have any effect on the cultureinfo of the wcf service. Also changes to the web.config (yes the service is hosted in iis) doesn't seem to work either.

Am I really left with only one option? Setting the CultureInfo programmaticly? I could find all the conversion calls and pass in a CultureInfo or i could set it on the Thread.CurrentThread.CurrentCulture. Is there no way i can set the CultureInfo once and for all - having effect on all the exposed wcf methods?

+1  A: 

You should check out this blog post...

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

... which shows how to define a behaviour for setting the culture.

HOWEVER, web.config should be your friend here. You should be able to set up the "default" culture that your service works with from here.

The globalization elemenent...

http://msdn.microsoft.com/en-us/library/hy4kkhe0.aspx

... should allow you to set the Culture and UICulture...

<globalization
    enableClientBasedCulture="true|false"
    requestEncoding="any valid encoding string"
    responseEncoding="any valid encoding string"
    fileEncoding="any valid encoding string"

    responseHeaderEncoding = "any valid encoding string" 
    resourceProviderFactoryType = string
    enableBestFitResponseEncoding = "true|false"

    culture="any valid culture string"
    uiCulture="any valid culture string"/>
Martin Peck
The blog post is nice but in my case it would mean rewriting the service a bit, as for the globalization element - i tried it but it didn't work - i guess i'll give it another try, perhaps i messed up :)
Per Hornshøj-Schierbeck
The globalization element doesn't seem to have any effect on the culture of the wcf thread.
Per Hornshøj-Schierbeck
Do you have anything else that might be influencing the culture? Web.config shoulld work.Is there any possibility that you can show us the code that is having problems? Are you being explicit with the culture that you're using. For example, if you're calling String.Format then are you using the overload that takes a CultureInfo?
Martin Peck
The whole problem is, that there are several calls to Convert methods (converting points and sizes) without passing the cultureinfo. Rather than rewriting/build the solution i would very much like to just configure it somewhere.
Per Hornshøj-Schierbeck
So, if you add the globalization element to web.config, and try setting culture AND uiCulture to something different to that which either your clients or service would be running under (e.g. fr-FR if you're in the US) then you don't see fr-FR as your current cultures (i.e. break point and check your Thread's culture properties)?
Martin Peck
The CurrentCulture and CurrentUICulture stays en-US no matter what i put in the globalization tag - just to make sure, it's supposed to go in the <system.web> element right?
Per Hornshøj-Schierbeck
A: 

You can use the config file as Martin mentioned above but as good practise you should definitely set the culture info wherever necessary to InvariantCulture to cater for data thats being sent through in different locales. ie dates, strings, numbers

Vixen
Good point. This is actually a Code Analysis check when using VSTS code analysis.
Diago
Yeah - if you run the code through FXCop and check the Globalization rules, it will point out all places where the culture should be defined.
Vixen
Yes but this is legacy code and i'm not supposed to setup code analysis or do rewriting on it if at all possible.
Per Hornshøj-Schierbeck
+1  A: 

The answer about using tag in web.config only works if Asp.net compatibility mode is enabled. You also need the following inside :

<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>

Without Asp.Net compatibility mode, the http modules are not used and the tag is ignored.

Spacebar
I don't know why i missed this, thanks :)
Per Hornshøj-Schierbeck