Before couple of weeks back, we spent the good amount of time figuring out from where an ASP.NET reads CultureInfo.CurrentCulture settings? Why? Because for one of our application it was English – UK and we wanted to change it to English – US.
Yes, we can modify it globally using web.config by setting [globalization culture=”en-US”]. But it will apply to whole application, Yes, you are right we can apply it on page as well. But it was working fine on our live server without configuration change either on page/config. And we wanted to know why? [Sometime rather than finding a solution, It’s good to find out a root cause]
We did a lot of read and finally, we fixed it and found the root cause. What, you are also searching for the same? Eager to know from where it reads? let’s go
To reproduce the issue, you can do following test scenario:
- Print “System.Globalization.CultureInfo.CurrentCulture” in a command prompt application
- Do the same in ASP.NET page — Simple Response.Write on sample page should do. [Make sure your site is hosted under IIS and running as NETWORK SERVICE user, same as live scenario]
- Now run both samples and note your CultureInfo
- Now, from Regional Settings do change your Culture settings.
- Repeat step#3
Analyzed the results? Surprised? Your changes will get reflected in console application. But not in ASP.NET application. Why?
We did a quick search and following thread came up :
As this thread says it reads it from System definitions
No matter what browser is in use, the definition for System.Globalization will always come from the Operating System definition
But our simple test says, it’s not true correct? Then from where it comes?
Also, did a quick search and found following thread:
And it did a trick!
Jason Evans’s comment pointed me in the right direction. See the link he posted: ASP.NET application doesn’t reflect Regional settings
It turns out that regional settings are stored per user in Windows. This is something I should have been aware of. Updating the application pool to run as myself produced the same result across both applications.
To be fair, what is still confusing is how Network Service (the account the application pool was running under) came to have the incorrect value. I’m not even sure how I’d rectify that.
If you need to update the regional settings for reserved accounts. You have two options.
- Control Panel > Regional Settings > Click the administrative tab and then select “Copy Settings”. On the screen that launches, ensure you check “Welcome Screen and system accounts”. Older versions of Windows are similar I believe.
- For the brace. Registry: HKEY_USERS > SID… > Control Panel > International. The security identifier for Network Service is: SID: S-1-5-20.
Ensure you restart the application pool for settings to take effect.
We followed approach#1, and it worked for us! [This is how it looks like!]
In summary, our ASP.NET application was running under NETWORK SERVICE user, and we were trying to change Regional settings for current logged in user and NOT Network Service user.
Happy Coding! 🙂