Сложная проблема с ресурсами и локализацией веб-форм ASP.NET

У меня нестандартная установка (VS2008, .NET 3.5 SP1):

Существует основной веб-проект под названием MainSite и несколько веб-проектов «плагинов» с разными именами.

При создании этих плагинов у меня есть собственный этап сборки, который вызывает aspnet_compiler.exe и aspnet_merge.exe. В результате получаются два файла .DLL - plugin_name .dll и plugin_name _deploy.dll. Первый содержит классы программной части, второй - код, сгенерированный из файлов .ascx.

Эти .DLL-файлы подключаемых модулей затем копируются в папку /MainSite/bin/Plugins/. Во время выполнения (запуск приложения) приложение MainSite просматривает эту папку и динамически загружает туда все файлы .DLL.

Все мои формы находятся в плагинах в файлах .ascx. Основное приложение - это просто каркас, который загружает эти пользовательские элементы управления .ascx по мере необходимости.

А теперь возникает необходимость в локализации. В идеале хотелось бы иметь следующее:

  • При создании ресурсов в Visual Studio для каждой формы должен быть отдельный файл ресурсов (файл .ascx), чтобы людям было проще локализовать формы параллельно.
  • Красивый метод meta:resourcekey в файлах .ascx очень удобен для локализации элементов управления;
  • Должен быть пригоден для использования механизм автоматического восстановления языка / культуры ресурсов в .NET;
  • Результат компиляции должен быть таким, чтобы файлы из всех плагинов можно было скопировать в папку /MainSite/bin/Plugins/. Если есть файл .DLL для каждого языка / культуры, и они должны быть помещены в какие-то определенные подпапки - это нормально, если .DLL-файлы из разных плагинов не имеют конфликтующих имен.

Есть идеи, как этого добиться?


person Vilx-    schedule 07.05.2009    source источник


Ответы (1)


По-видимому, в .NET можно реализовать собственные поставщики ресурсов. Здесь находится статья, содержащая ссылки на различные другие статьи, объясняющие весь процесс. Фактически, вы берете значение из meta:resourcekey и получаете значение откуда угодно. В статье выше, например, вся информация о локализации хранится в БД.

person Vilx-    schedule 08.05.2009