Глобализация неправильно использует культуру по умолчанию во всех сценариях после развертывания

Question

локальной среды:
Win10 x64
VS 2015 Pro Обновления 3
IIS 10.0 Экспресса

производственной среды:
Win сервер 2012 R2
IIS 8.5

Im разрабатывает приложение ASP.NET 4.6.1 MVC, которое должно поддерживаться на английском, датском и голландском языках. Я реализую нейтральные культуры, поскольку они интересуются только языком, а не спецификой. Я использую спутниковые сборки (как их называли некоторые) или, скорее, файлы Resource.resx для моих переводов. Первый подход я следовал this often referenced post, и он отлично работает локально. Как только я развожу его в производственную среду, переводы перестают работать. Я установил потоки в соответствии с значениями базы данных: И я подтвердил, что этот метод всегда корректно выполняется в рабочей среде. Я пробовал устанавливать потоки, как на ссылочном посту, а также хорошо работает локально, но не в производстве. И я даже попробовал установить его прямо, как верхняя часть моих просмотров с помощью бритвы безрезультатно.
Что меня поразило, так как это было странно, так это то, что он работал один раз в рабочей среде после того, как я немного поиграл, но я уверен, что я действительно ничего не делал, и вдруг это сработало. К сожалению, она перестала работать после того, как я развернул обновление для приложения, и с тех пор я не смог заставить его работать. С тех пор я пытался возиться со всеми настройками в среде .NET на IIS для этого веб-сайта и для корневого каталога:
Но даже с указанием да-DK или -да как культура здесь или непосредственно в Интернете .config моего приложения или hardcoding поток для использования da, поскольку культура не помогает вообще. Смешно, что число и формат даты корректно меняются. Таким образом, похоже, что проблема связана с тем, что поток не изменил свою культуру, а IIS отказался использовать другие файлы ресурсов. При развертывании структура папок содержит папку da в bin и содержит файл с именем Resources.resources.resx, который, я считаю, верен. Я пытался иметь файлы ресурсов, находящиеся в библиотеке классов, как предлагает статья, но также и в папке в том же проекте из-за разочарования. Файлы ресурсов имеют общедоступную доступность и скомпилированы как встроенные ресурсы без копирования файлов.

Итак, мой вопрос: почему IIS отказывается использовать любой другой файл ресурсов, чем по умолчанию? И как это возможно, что он работал один раз? На данный момент я рассматриваю только перевод переводов в базу данных, потому что, по крайней мере, это работает. Какие у вас есть предложения? Я полагаю, что среда .NET в IIS имеет все необходимые языки, поскольку они видны в настройках глобальной платформы .NET, но я могу ошибаться?

Обновление: я попробовал, как было предложено NightOwl, снова он работает локально (отладка VS) и даже если я размещаю развернутые файлы в iisexpress на своей машине. Но он все еще терпит неудачу в производственной среде. Предлагаемый метод аналогичен this, но все же безуспешно. Я начинаю думать, что решение состоит в том, чтобы перейти на iis 10 в производственной среде.

Answer 1

Проблема была вызвана пакетом Nuget SimpleImpersonation, который, как представляется, изменил культуру текущего потока за кулисами. Кажется, он изменил его обратно до значения по умолчанию после его удаления, но поскольку я устанавливал культуру, пока ссылка была действительной, она всегда возвращалась обратно в en-US. По-прежнему странно, что он работал локально в IIS Express 10.0. Но по крайней мере сейчас это работает для обеих сред ...

Answer 2

Эта статья, кажется, есть некоторые заранее MVC идеи в виду:

• Файлы ресурсов не поддерживаются полностью в MVC (по крайней мере, без хаков) - см Resource Files and ASP.NET MVC Projects. Однако вы можете использовать embedded resources или использовать ResourceManager, чтобы загрузить внешние ресурсы.
• Настройка языка пользователя в соответствии с настройками браузера обычно является неправильным выбором. Вместо этого вы должны использовать URL-адрес для передачи информации о культуре, чтобы поисковые системы могли сканировать и индексировать их. Локализация содержание не персонализация. Опираясь на заголовки, чтобы отобразить правильный язык, вы можете разочаровать пользователей, которые сидят за брандмауэрами, которые меняют эти заголовки. Использование URL для выбора языка дает прямой контроль над языком для пользователя.

См. Мой ответ на вопрос ASP.NET MVC 5 culture in route and url за простой способ MVC для локализации.

В принципе, ответ на ваш вопрос находится в this link - по умолчанию ресурсы в App_GlobalResources являются внутренними и не могут использоваться без изменения настроек. Они требуют особого внимания во время развертывания или не будут развернуты с вашим приложением. App_LocalResources вообще не поддерживаются в MVC (они предназначены для устаревших страниц ASP.NET). Короче: избегайте App_GlobalResources и App_LocalResources (у которого есть свой набор проблем) в MVC.

Не по теме: Похоже, вы также с использованием базового контроллера (из-за метода Initialize). Это тесно связывает ваше приложение вместе. Лучше всего использовать глобальные фильтры, каждый из которых может содержать единую функциональность. См. this answer.