Глобализация сборок, созданных во время выполнения

Question

Предыстория

Проект устанавливает некоторые файлы, которые содержат все элементы для определения UserControl - некоторый пользовательский исходный код, CodeCompileUnit для кода конструктора и resx-файл.Во время выполнения эти файлы компилируются в сборку, и классы используются нашим основным приложением (сборка обновляется только при необходимости).

Вопрос

Проект должен быть глобализирован, и как часть этого процесса необходимо обеспечить локализацию этих файлов.Есть два варианта: либо разрешить включение дополнительных файлов resx для разных локализаций (либо в рамках одних и тех же файлов, либо в виде дополнительных параллельных файлов), которые могут быть скомпилированы во вспомогательную сборку для основной сборки, либо предоставить копию каждого полного файла для каждого поддерживаемого языка, скомпилировав соответствующий набор для поддерживаемого языка.

• Есть ли у кого-нибудь другие варианты, которые, возможно, стоит рассмотреть?
• Какие проблемы могут быть присущи любому из предложенных мной решений?

---

Ограничения/ Отказ от ответственности
Я осознаю, что сценарий далек от идеального и что в некоторых областях можно было бы сделать лучший выбор (например, глобализировать с самого начала), но они не могут быть изменены на данном этапе проекта.Я ценю любые советы, решения или зацепки, которые вы можете предоставить.Спасибо.

Answer 1

Создайте отдельную вспомогательную сборку для каждой культуры.Это имеет два преимущества:

• Вы можете собрать все сборки за один раз и иметь определенный файл для каждого номера версии и комбинации имен файлов, а не для него также в зависимости от культуры.
• Вы можете использовать несколько сборок в одной установке и использовать язык в зависимости от языка системы, предпочтений пользователя и т.д.Это значительно упростит разработку и тестирование, поскольку вам не нужно будет постоянно перестраивать и копировать файлы только ради смены языков.
• Именно так должен работать .NET i18n.Хотя я не эксперт по .NET i18n ("прочитайте книгу Гая Смита-Ферье" - мой лучший совет!) Я обычно нахожу, что фреймворки работают лучше всего, когда вы следуете их ожидаемой модели.

Даже если заключительная часть "сборки сателлита" выполняется во время выполнения (можете ли вы сделать это в установить время вместо этого?) вы по-прежнему получаете преимущества по крайней мере во втором и третьем пуле.Это также означает, что если вы когда - нибудь делай пойдите по более обычному пути поставки сборок сателлитов для начала (вместо того, чтобы создавать их на поле пользователя), и вам придется меньше менять.

Однако прошу прощения, если я неправильно понял вопрос...

Answer 2

Если вы не планируете добавлять дополнительные языки после развертывания (по крайней мере, без обновления программного обеспечения), то я бы предпочел скомпилировать все дополнительные файлы RESX в вспомогательную сборку, которую вы включаете.Таким образом, они недоступны для редактирования пользователем после их развертывания.