4

I have a strange issue occurring on my Windows 8 dev box. The following line of code results in two different values for the NumberFormat.NumberDecimalSeparator when comparing an ASP .NET application running Kentico and a console application (both running on .NET 4.0).

var culture = new System.Globalization.CultureInfo("en-ZA");
var separator = culture.NumberFormat.NumberDecimalSeparator;

The value of seperator:

  1. Kentico application: "," <- comma
  2. Console application: "." <- period

The correct output for my regional setting is a period.

How is this possible? When I first picked up a formatting issue for decimal numbers, I thought it may have been a Kentico bug, however this test indicates otherwise. How is it possible that a new instance of CultureInfo for a specific locale returns an instance that differs across applications?

Rohland
  • 1,405
  • 14
  • 20

2 Answers2

11

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.

Edit:

If you need to update the regional settings for reserved accounts. You have two options.

  1. 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.
  2. For the brave. 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.

Community
  • 1
  • 1
Rohland
  • 1,405
  • 14
  • 20
2

EDIT: Note that this wasn't the issue - but in other cases it could be, so I'm leaving it here for posterity.

I strongly suspect that the console application isn't running on .NET 4.0. It's easy enough to verify that using Environment.Version though. Here's a short console app and results via two different versions of the framework:

using System;
using System.Globalization;

class Test
{
    static void Main()
    {
        CultureInfo culture = new System.Globalization.CultureInfo("en-ZA");
        string separator = culture.NumberFormat.NumberDecimalSeparator;
        Console.WriteLine("Version: {0}", Environment.Version);
        Console.WriteLine("Separator: {0}", separator);
    }
}

Compiling against .NET 4.5:

Version: 4.0.30319.18010
Separator: ,

Compiling against .NET 2.0:

Version: 2.0.50727.6400
Separator: .

Try this code in both applications, and see what versions they're running.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • No, I get the same result for both apps for version number: 4.0.30319.18010. – Rohland Jan 14 '13 at 17:03
  • That's surprising. What about `Environment.Is64BitProcess`? Admittedly it would be odd for the architecture to make a difference, but you never know... – Jon Skeet Jan 14 '13 at 17:07
  • Thanks Jon. Turned out to be simple in the end. I didn't think to run both under my account. Turns out regional settings are user specific. Somehow my Network Service account had a tweaked set of values. – Rohland Jan 14 '13 at 17:32
  • @Rohland: Right - I'll leave this answer up for future readers but edit appropriately. – Jon Skeet Jan 14 '13 at 17:37
  • This was an OS change in Windows 8. Just got bitten by it. :( – leppie Mar 26 '14 at 09:44