Unicode string comparison and CType differences on server vs. development environment

Sorry in advance for the long winded question.

We have inherited a large ASP.NET application written in ASP.NET that is heavily localized into a number of languages. At various points in our application we have server side code (in VB.NET) that compares two strings which are potentially in unicode.

We have noticed a number of differences between the application that runs fine in our test and development environment but causes issues in our production environment. All environments are .NET 4.0 SP1 and SQL 2008 R2. The environments do differ in OS (works in Win 2008 Svr, IIS 7 but does not in Win 2003 Svr, IIS 6). We have compared the .NET versions and service packs on these environments, validated our SQL servers were identical and all collation settings match at the server and database level, verified all deployed code matches between our environments, and done our best to otherwise determine why we are noticing the diff开发者_StackOverflow中文版erence below. We've also verified both sites are running under the same .NET framework version and basic AppPool settings.

Some of the differences are:

This legacy application uses the VB.NET CType method in a number of places to convert what ultimately is a string into an integer. For example, CType(strData, Integer). In all dev and test environments this works fine but in production we get exceptions on this line and are methodically converting it to Int32.Parse(strData, Integer). We are confused as to why the difference in environments with this line of code. If it doesn't cause an exception on any developers machine or in our test environment, what might we look for that enforces this constraint in production? The exception thrown is an "Invalid Cast from "3" to Integer" which makes sense but we don't understand what would cause some environments to allow this cast and others to throw the exception.

A significantly more important difference between environments is in the comparison of Unicode strings. We have a number of places where we compare strings that are in Chinese or other asian character-based languages. We know these strings to be equal and both are loaded from the same point in the database. These comparisons are fine (and result in a true) in all environments except the ill-fated production. We have tried a number of means of comparison (" = ", Compare w/ InvariantCulture, etc) and still cannot get our matching strings to match. We have confirmed that the server has East Asian languages installed and we can see them correctly when controlling the server. If we have a ASP.NET dropdown with a Chinese word as the value and we set the cboDropdown.SelectedValue to an exact match of the same Chinese word the dropdown does not recognize this match. All of these comparisons and usage of unicode comparisons work fine in all other environments.

I know this is a long question but does anyone have any ideas of what settings or environment differences would cause our application to behave so differently in one environment while running very effectively in others? Why would the same string comparisons differ so much?

Languages are depending also on Operating system. especially Chinese unicode system Simplified chinese. If you want to use unicode Languages . I recommend to not just use "a" unicode system like VS does promote with system.text.encoding.unicode Use a language table Language table like

System.Text.Encoding.GetEncoding(936)

Perhaps this could be interested too in this case Encoding MSDN and Supported code pages

Regards