Глобализация сборок во время выполнения
Фон
Проект устанавливает несколько файлов, которые содержат все элементы для определения UserControl - некоторый пользовательский источник, CodeCompileUnit для кода разработчика и файл resx. Во время выполнения эти файлы компилируются в сборку, и классы используются нашим основным приложением (сборка обновляется только при необходимости).
Вопрос
Проект должен быть глобализирован, и как часть этого процесса необходимо обеспечить локализацию этих файлов. Два варианта: либо разрешить включение дополнительных файлов resx для разных локалей (либо внутри одних и тех же файлов, либо в виде дополнительных параллельных файлов), которые можно скомпилировать в вспомогательную сборку для основной сборки, либо предоставить копию каждый полный файл для каждого поддерживаемого языка, компилируя соответствующий набор для поддерживаемого языка.
- У кого-нибудь есть другие варианты, которые стоит рассмотреть?
- Какие проблемы могут быть присущи любому из предложенных мной решений?
Ограничения / Отказ от ответственности
Мне известно, что сценарий далеко не идеален и что в некоторых областях можно было бы сделать лучший выбор (например, глобализация с самого начала), но их нельзя изменить на данном этапе проекта. Я ценю любые советы, решения или рекомендации, которые вы можете предоставить. Благодарю.
2 ответа
Создайте отдельную спутниковую сборку для каждой культуры. Это имеет два преимущества:
- Вы можете собрать все сборки за один раз, и иметь определенный файл для каждого номера версии и комбинации имен файлов, а не в зависимости от культуры.
- У вас может быть несколько сборок в одной и той же установке, и вы можете использовать язык на системном языке или на предпочтениях пользователя и т. Д. Это значительно упростит разработку и тестирование, поскольку вам не нужно будет перестраивать и копировать файлы просто ради смены языков.
- Так работает.NET i18n. Хотя я не эксперт по.NET i18n ("читай книгу Гая Смита-Ферье" - мой лучший совет!), Я обычно нахожу, что фреймворки работают лучше всего, когда вы следуете их ожидаемой модели.
Даже если заключительная часть "сборки спутниковой сборки" будет выполнена во время выполнения (можете ли вы сделать это во время установки вместо этого?), Вы все равно получите как минимум второе и третье преимущество. Это также означает, что если вы когда-нибудь пойдете по более обычному пути поставки спутниковых сборок для начала (вместо того, чтобы строить их на ящике пользователя), у вас будет меньше изменений.
Извиняюсь, если я неправильно понял вопрос...
Если вы не планируете добавлять дополнительные языки после развертывания (по крайней мере, без обновления программного обеспечения), то я бы предпочел собрать все дополнительные файлы RESX в добавляемую вами сборку сателлитов. Таким образом, они не будут редактироваться пользователем после развертывания.