【发布时间】：2011-05-03 18:02:22
【问题描述】：
对于这个冗长的问题，我们深表歉意。
我们继承了一个用 ASP.NET 编写的大型 ASP.NET 应用程序，该应用程序大量本地化为多种语言。在我们的应用程序的各个点，我们都有服务器端代码（在 VB.NET 中），它比较两个可能是 unicode 的字符串。
我们注意到在我们的测试和开发环境中运行良好但在生产环境中导致问题的应用程序之间存在许多差异。所有环境都是 .NET 4.0 SP1 和 SQL 2008 R2。操作系统的环境确实不同（在 Win 2008 Svr、IIS 7 中有效，但在 Win 2003 Svr、IIS 6 中无效）。我们已经比较了这些环境中的 .NET 版本和服务包，验证了我们的 SQL 服务器是相同的，并且所有排序规则设置在服务器和数据库级别匹配，验证了我们环境之间所有部署的代码匹配，并尽最大努力确定我们为什么注意到下面的区别。我们还验证了两个站点都在相同的 .NET 框架版本和基本 AppPool 设置下运行。
其中一些区别是：
这个遗留应用程序在许多地方使用 VB.NET CType 方法将最终的字符串转换为整数。例如，CType(strData, Integer)。在所有开发和测试环境中，这都可以正常工作，但在生产中，我们会在这条线上遇到异常，并有条不紊地将其转换为 Int32.Parse(strData, Integer)。我们对为什么这行代码的环境差异感到困惑。如果它不会在任何开发人员机器或我们的测试环境中导致异常，我们会寻找什么来在生产中强制执行此约束？抛出的异常是“从“3”到整数的无效转换”，这是有道理的，但我们不明白什么会导致某些环境允许此转换而其他环境抛出异常。
环境之间更重要的区别在于 Unicode 字符串的比较。我们有很多地方可以比较中文或其他基于亚洲字符的语言的字符串。我们知道这些字符串是相等的，并且它们都是从数据库中的同一点加载的。这些比较在所有环境中都很好（并且结果是真的），除了命运多舛的生产。我们尝试了多种比较方法（“=”、比较 w/ InvariantCulture 等），但仍然无法匹配匹配的字符串。我们已经确认服务器安装了东亚语言，我们在控制服务器时可以正确看到它们。如果我们有一个以中文单词作为值的 ASP.NET 下拉菜单，并且我们将 cboDropdown.SelectedValue 设置为与同一个中文单词完全匹配的下拉菜单，则该下拉菜单无法识别此匹配。所有这些比较和 unicode 比较的使用在所有其他环境中都可以正常工作。
我知道这是一个很长的问题，但是否有人知道哪些设置或环境差异会导致我们的应用程序在一个环境中表现如此不同，而在其他环境中却非常有效地运行？为什么相同的字符串比较会有这么大的差异？
【问题讨论】：
-
我的直觉反应是调查 machine.config 文件，看看是否有更严格的政策正在某个地方执行。