Silverlight on Windows Server 2012: CultureNotFoundException("zh-Hans-CN") thrown, but machine is localized to zh-CN

Question

I have a Silverlight 4 application hosted on a Windows Server 2012 machine. The server is localized to Chinese (Simplified), culture code zh-CN. I confirmed this with the following powershell:

PS C:\> get-culture

LCID             Name             DisplayName
----             ----             -----------
2052             zh-CN            Chinese (Simplified, PRC)

get-UICulture returned en-us, which I suspect is because I am RDPing from an en-us machine. I confirmed that the UI culture is set to zh-CN via the Control Panel Regions settings.

When exceptions are being thrown from the app, it appears that a CultureNotFoundException is being thrown while constructing details of the original exception.

Simplified example:

List<string> items = { "a", "a" };
items.ToDictionary();

Resultant callstack:

System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) // throws a CultureNotFoundException referencing zh-Hans-CN
System.Collections.Generic.Dictionary.Insert(...) // throws an ArgumentException "Duplicate Key Added"
System.Linq.Enumerable.ToDictionary(...)

The details of the exception that we report via the Silverlight app are

[Argument_CultureNotSupported]
参数: 
调试资源字符串不可用。密钥和参数通常提供足够的信息用以诊断该问题。请访问 http://go.microsoft.com/fwlink/?linkid=106663&Version=5.0.10411.00&File=mscorlib.dll&Key=Argument_CultureNotSupported
参数名: name
[Argument_CultureInvalidIdentifier]
参数: zh-Hans-CN
调试资源字符串不可用。密钥和参数通常提供足够的信息用以诊断该问题。请访问 http://go.microsoft.com/fwlink/?linkid=106663&Version=5.0.10411.00&File=mscorlib.dll&Key=Argument_CultureInvalidIdentifier

Within the Silverlight app, string resources are being correctly localized to zh-CN, but it appears that the underlying .Net exception-construction code thinks the app is in zh-Hans-CN. This causes exceptions to be reported even when the original exception is correctly handled/suppressed/discarded.

Browsing from an en-us machine, CultureNotFoundExceptions are NOT thrown as part of the exception process. Rather, I see the real "Duplicate Key added" ArgumentException in the above example.

I attempted to change the web.config globalization settings to include

<system.web>
  <globalization culture="zh-CN" uiCulture="zh-CN" />
</system.web>

as described here with no noticeable change in behavior.

I've read up on zh-CN vs. zh-CHS vs. zh-Hans-CN vs. zh-Hans, and it's all quite baffling to a non-Chinese speaker. I added zh-Hans resources to the Silverlight .xap in addition to the original zh-CN, but this did not change behavior.

My intuition is that the .Net client core is seeking zh-Hans-CN or zh-Hans resources that are not installed on the machine, despite the machine definitely having zh-CN resources and being in zh-CN by every test I can think of.

My specific objective here is to prevent the CultureNotFoundExceptions from being thrown, as they are causing red herrings and are obfuscating real exceptions that are coming out of the code due to other valid localization exceptions.

Any help is very much appreciated!

Answer 1

There were a number of things going on here:

1) The Silverlight code set the System.Thread.CurrentThread.CurrentCulture to the server's culture, zh-CN, even though that language pack was not installed.

2) The Silverlight code was throwing a valid .Net library exception (I believe InvalidOperationException).

3) During the exception processing of the InvalidOperationException, the .Net framework attempted to look up the localization string for zh-CN (current thread's current culture). Unable to find that (language pack not installed), it then looked for other language/culture combos per the culture prioritization rules. When it finally got to zh-Hans-CN (the last in the chain), it failed for the last time and threw the CultureNotSupportedException.

4) The CultureNotFoundException superseded the original InvalidOperationException, causing that exception to be reported to the user/log.

The eventual fix was to remove the code that set the Silverlight's CurrentThread.CurrentCulture to the server's locale. This was an artifact from a previous hack that was obsolete anyway.