Спутниковая сборка не воспринимается приложением ASP.NET

У меня есть веб-проект под названием "TestResourceApp" с Labels.resx в папке App_GlobalResources. Я хочу добавить другой язык, создав спутниковую сборку.

Вот шаги, которые я предпринял для создания спутниковой сборки. Текст по умолчанию всегда отображается. Что я сделал не так?

1) Создайте Labels.fr.resx в другой папке.

2) Создать файл ресурсов:

Resgen Labels.fr.resx TestResourceApp.App_GlobalResources.Labels.fr.resources

3) Генерация спутниковой сборки:

AL / t: lib /embed:TestResourceApp.App_GlobalResources.Labels.fr.resources /out:french.dll / c: fr

4) Скопируйте french.dll в TestResourceApp/bin/fr

В web.config для uiculture установлено значение auto, и я изменил язык в браузере.

Источник

3 ответа

Решение

Это сложно, но вот несколько советов для тех, кто сталкивается с этой проблемой:

  • Попробуйте включить resx в веб-проект, и пусть VS сделает всю работу за вас.
  • Отражатель твой друг. Сравните сателлитные сборки, которые вы создали, и те, которые созданы VS.
  • Если ваше веб-приложение предназначено для ASP.NET 2.0, вы должны использовать Resgex и AL, которые поставляются с.net 2.0. Откройте сборки в Reflector и проверьте "ссылки". Он должен ссылаться на mscorlib версии 2.0.
  • Если вы развертываете свое веб-приложение с помощью проекта веб-развертывания, убедитесь, что пространство имен для ресурсов в ваших сателлитных сборках правильное. Опять же, сравните с тем, что создает VS. В моем случае я использовал неправильный инструмент для создания файла designer.cs, потому что хотел, чтобы они были доступны из другой сборки. Убедитесь, что вы используете GlobalResourceProxyGenerator. В противном случае пространства имен не будут совпадать, и код развертывания не сможет найти ваш ресурс. Пространство имен в файле designer.cs должно быть просто "Ресурсы", а не "XXXX.App_GlobalResources".
Источник

Я смог использовать эту страницу, чтобы решить некоторые проблемы со сборкой спутника, которые у меня были. Я добавлю еще несколько вещей, чтобы проверить.

Полезно декомпилировать "нейтральную" сборку и посмотреть, как она собрана. Инструмент как ILDASM.exe полезно для этой цели. Как только вы получите декомпилированный файл, просмотрите текстовый вывод ".mresource", и вы должны увидеть его с вашим именем. Например, если вы добавляете ресурс в проект Visual Studio, он называется MyAssemblyName + ".Properties.Resources" + язык (если есть) + ".resources". Примеры:

MyAssembly.Properties.Resources.resources (нейтральный язык) MyAssembly.Properties.Resources.en-US.resources (английский (США))

В моем случае файл был назван правильно и в соответствующей папке (например, Bin\en-US). Я смог проверить это с помощью ProcMon.exe (парнями из SysInternals) и мог видеть, как рабочий процесс находит и читает в моем файле DLL (вместо того, чтобы просто сказать "ПУТЬ НЕ НАЙДЕН"). Однако он не находил ресурс по названию, которого ожидал. Именно тогда некоторая разборка помогла разобраться с проблемой именования.

Итак, используйте ProcMon.exe чтобы сузить тип проблемы, которую вы могли бы иметь. Надеюсь, это кому-нибудь пригодится.

Источник

Вы установили enableClientBasedCulture в true в глобализации?

Источник
Другие вопросы по тегам