Заранее извините за длинный вопрос.
Мы унаследовали большое приложение ASP.NET, написанное на ASP.NET, которое в значительной степени локализовано на несколько языков.В разных точках нашего приложения у нас есть серверный код (в VB.NET), который сравнивает две строки, которые потенциально могут быть в юникоде.
Мы заметили ряд различий между приложением, которое отлично работает в нашем тесте, исреда разработки, но вызывает проблемы в нашей производственной среде.Все среды .NET 4.0 SP1 и SQL 2008 R2.Среды различаются по ОС (работает в Win 2008 Svr, IIS 7, но не в Win 2003 Svr, IIS 6).Мы сравнили версии .NET и пакеты обновления в этих средах, проверили, что наши SQL-серверы идентичны, и все параметры сопоставления совпадают на уровне сервера и базы данных, проверили все развернутые коды кода в наших средах и постарались определить, почему мызаметили разницу ниже.Мы также убедились, что оба сайта работают под одной и той же версией .NET Framework и базовыми настройками AppPool.
Вот некоторые различия:
Это устаревшее приложение использует метод VB.NET CType вколичество мест для преобразования строки в целое число.Например, CType (strData, Integer).Во всех средах разработки и тестирования это работает нормально, но в производственной среде мы получаем исключения для этой строки и методично конвертируем ее в Int32.Parse (strData, Integer).Мы не понимаем, почему разница в средах с этой строкой кода.Если это не вызывает исключений на машинах разработчиков или в нашей тестовой среде, что мы можем искать, чтобы усилить это ограничение в работе?Исключением является «Неверное приведение от« 3 »к целочисленному», что имеет смысл, но мы не понимаем, что может привести к тому, что некоторые среды позволят этому приведению, а другие сгенерируют исключение.
Значительно более важноРазница между средами заключается в сравнении строк Unicode.У нас есть несколько мест, где мы сравниваем строки на китайском или других азиатских символьных языках.Мы знаем, что эти строки равны и обе загружаются из одной и той же точки в базе данных.Эти сравнения хороши (и приводят к истинности) во всех средах, кроме злополучного производства.Мы попробовали несколько способов сравнения ("=", Compare w / InvariantCulture и т. Д.) И до сих пор не можем сопоставить совпадающие строки.Мы подтвердили, что на сервере установлены восточноазиатские языки, и мы можем правильно их видеть при управлении сервером.Если у нас есть раскрывающийся список ASP.NET с китайским словом в качестве значения, и мы устанавливаем для cboDropdown.SelectedValue точное совпадение с тем же китайским словом, раскрывающийся список не распознает это совпадение.Все эти сравнения и использование юникодных сравнений прекрасно работают во всех других средах.
Я знаю, что это длинный вопрос, но есть ли у кого-нибудь идеи о том, какие настройки или различия в среде приведут к тому, что наше приложение будет вести себя по-разному в одной среде, а в других - очень эффективно?Почему одни и те же сравнения строк так сильно различаются?