1

I have a 64bit server that we are running an application on in 32bit mode.

For whatever reason the locale of the 32bit process is coming through as en-US when the server is set to en-GB.

I am guessing that the reason for this is there is that the 64bit and WOW64 are not sharring the locale settings.

So my question is how do you set the locale for a 32bit process?

This is Windows 2003. The application is an asp.net app running under IIS in 32bit mode. This setup is definitely not my choice.

5
  • out of curiosity what would you change about the setup?
    – Jim B
    Apr 30, 2010 at 14:48
  • I can't see why you would run 32bit applications on a 64bit server. Especially when they are .NET apps that will run natively as 64bit. Running in WOW64 mode introduces numerous problems that make you want to curl up in a ball and suck your thumb. Apr 30, 2010 at 14:55
  • ...Yeah. Excel, though, becomes the problem. There's no 64-bit Excel so all of the tools that interface with it have to use their 32-bit counterparts.
    – squillman
    Apr 30, 2010 at 15:10
  • You get other problems with WOW64. There is a real humdinger when using IIS management scripts. You have to register 32bit COM. And you have to be careful when you do that to do it in a 32bit cmd shell. Now the default cmd shell is 64bit.. but misleading thing is that it says it is \windows\system32. However the way WOW64 works is to redirect calls to 32bit files from the system32 dir to special WOW64 directories. It really does make you go crazy. I understand how it works, but it makes zero sense. Apr 30, 2010 at 15:38
  • There is a 64 bit excel (well now there is with 2010). Yeah I can see your point about the management scripts but once the dlls have been copied , its done. We don't build any 32 bit servers anymore.
    – Jim B
    Apr 30, 2010 at 17:41

1 Answer 1

1

It's probably a setting in your ASP.NET application. Locale on the server should be global regardless of process architecture. Look in the app's web.config for a <globalization /> tag that could be setting it to en-US. Here's the MSDN reference for the globalization element.

It could also be written into the application code. Globalization can be set at the thread level in .NET.

EDIT
From your comment, I'm thinking that maybe your Excel workbook itself has the data set to en-US internally. Open the file and reformat the cells to use en-GB.

  1. Select all the cells with date
  2. Right-click on the selection and do Format Cells...
  3. On the Number tab, choose Date from the Category list
  4. Verify the Locale in the drop-down underneath the Type:

See if that does it for you.

3
  • So I tried that. But the application actually calls creates an oledb connection to an excel file. The dates that we receive from the excel document are then in US format. When we run the same code on a 32bit computer set to en-GB it gets them in UK format - thus my theory it is some sort of 64bit/32bit WOW64 issue. Apr 30, 2010 at 14:53
  • @Derek: see my edit above.
    – squillman
    Apr 30, 2010 at 15:17
  • Unfortunately it doesn't make a difference. In fact on my machine the file is en-US and on my colleagues it is en-GB (same file unmodified). When we upload either file then both are read as US. Also we need to be able to read any file without people explicitly setting the locale. Apr 30, 2010 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .