Создание вспомогательных сборок
При разработке приложений, использующих ресурсы, рекомендуется применять модель "звезда", описанную в разделе Упаковка и развертывание ресурсов.
Для реализации этой модели необходимо разместить ресурсы в определенных местах, чтобы их можно было легко искать и использовать. Если ресурсы расположены неверно или они компилируются и именуются не так, как требует общая среда исполнения, она не сможет их найти. В результате среда исполнения будет использовать стандартный набор ресурсов. Дополнительные сведения об именах ресурсов см. в разделах Класс CultureInfo или Упаковка и развертывание ресурсов.
Компиляция вспомогательных сборок
Для компиляции файлов .resources во вспомогательные сборки используется компоновщик сборок (Al.exe). Программа Al.exe создает сборку из указанных файлов .resources. Вспомогательные сборки по определению могут содержать только ресурсы. В них не может присутствовать исполняемый код.
Для создания вспомогательной сборки для приложения MyApp из файла strings.de.resources служит следующая команда Al.exe.
al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
Для создания вспомогательной сборки для приложения MyApp из файла strings.de.resources служит и следующая команда Al.exe. Параметр /template задает наследование метаданных вспомогательной сборки из родительской сборки MyApp.dll.
al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
/template:MyApp.dll
В приведенной ниже таблице более подробно описываются параметры Al.exe, использованные в этих примерах.
Параметр |
Описание |
---|---|
/t:lib |
Параметр /t указывает, что вспомогательная сборка компилируется в файл библиотеки (.dll). Вспомогательная сборка не может быть выполнена, так как она не содержит кода и не является основной сборкой приложения. Поэтому вспомогательные сборки необходимо сохранять в качестве библиотек DLL. |
/embed:strings.de.resources |
Параметр /embed указывает для программы Al.exe имя исходного файла, используемого при компиляции сборки. Обратите внимание, что во вспомогательной сборке можно объединить несколько файлов .resources. Однако при использовании модели "звезда" для каждого языка и региональных параметров необходимо компилировать отдельную вспомогательную сборку. Впрочем, можно создавать отдельные файлы .resources для строк и объектов. |
/culture:de |
Параметр /culture задает язык и региональные параметры компилируемого ресурса. Среда выполнения использует эти сведения в процессе поиска ресурсов, относящихся к указанному языку и региональным параметрам. Если этот параметр опустить, программа Al.exe скомпилирует ресурс, но среда выполнения не сможет его найти по запросу пользователя. |
/out:MyApp.resources.dll |
Параметр /out указывает имя выходного файла. Имя должно соответствовать шаблону baseName.resources.extension, где baseName — имя основной сборки, а extension — допустимое расширение (например, .dll). Обратите внимание, что среда выполнения не может определить язык и региональные параметры вспомогательной сборки на основании имени выходного файла. Поэтому важно указывать язык и региональные параметры с помощью вышеописанного параметра /culture. |
/template:имя_файла |
Параметр /template указывает на сборку, из которой наследуются все метаданные сборки, кроме поля языка и региональных параметров. Сборка, из которой наследуется вспомогательная сборка, должна иметь строгое имя. |
Полный список параметров, доступных в программе Al.exe, см. в разделе Компоновщик сборок (Al.exe).
Компилирование вспомогательных сборок со строгими именами
Если требуется установить вспомогательные сборки в глобальный кэш сборок, у них должны быть строгие имена. Сборки со строгими именами должны быть подписаны допустимой парой ключей "открытый-закрытый". Для получения дополнительных сведений о строгих именах см. раздел Сборки со строгими именами.
Разработчик приложения, как правило, не имеет доступа к итоговой паре открытого и закрытого ключей. Чтобы установить вспомогательную сборку в глобальный кэш сборок и обеспечить ее работоспособность, можно воспользоваться средством отложенной подписи. Если подписание сборки откладывается, во время построения в файле резервируется место для подписи со строгим именем. Фактически подписание откладывается до того момента, когда становится доступной итоговая пара открытого и закрытого ключей.
Получение открытого ключа
Чтобы отложить подпись сборки, необходимо иметь доступ к открытому ключу. Открытый ключ можно либо получить в организации, которая будет заниматься окончательным подписанием, либо создать самостоятельно с помощью программы строгих имен (Sn.exe).
Следующая команда Sn.exe создает тестовые открытый и закрытый ключи и сохраняет их в файле TestKeyPair.snk. Параметр –k указывает, что необходимо создать новую пару ключей и сохранить ее в заданном файле.
sn –k TestKeyPair.snk
Открытый ключ можно извлечь из файла, содержащего тестовую пару ключей. Следующая команда извлекает открытый ключ из файла TestKeyPair.snk и сохраняет его в файле PublicKey.snk.
sn –p TestKeyPair.snk PublicKey.snk
Отложенная подпись сборки
Получив или создав открытый ключ, можно скомпилировать сборку и указать отложенную подпись, используя компоновщик сборок (Al.exe).
Для создания вспомогательной сборки со строгим именем для приложения MyApp из файла strings.ja.resources служит следующая команда Al.exe.
al /t:lib /embed:strings.ja.resources /culture:ja /out:MyApp.resources.dll /delay+ /keyfile:PublicKey.snk
Параметр /delay+ указывает, что подпись сборки должна быть отложена. Параметр /keyfile: задает имя файла ключа, в котором содержится открытый ключ, применяемый для откладывания подписи сборки.
Дополнительные сведения об отложенной подписи см. в разделе Отложенная подпись сборки.
Обратите внимание, что сборки со строгими именами содержат сведения о версии, с помощью которых среда выполнения определяет, какую сборку следует использовать для удовлетворения запроса компоновщика. Дополнительные сведения по этой теме см. в разделе Отслеживание версий сборок.
Повторная подпись сборки
В конечном итоге вспомогательная сборка с отложенной подписью должна быть подписана заново парой реальных ключей. Это можно сделать с помощью программы Sn.exe.
Для подписи MyApp.resources.dll с помощью пары реальных ключей, хранящихся в файле RealKeyPair.snk, используется следующая команда Sn.exe. Параметр –R указывает, что нужно заново подписать уже подписанную сборку или сборку с отложенной подписью.
sn –R MyApp.resources.dll RealKeyPair.snk
Установка вспомогательной сборки в глобальный кэш сборок
Глобальный кэш сборок является первым местом, где среда выполнения ищет ресурсы в процессе перехода на резервные средства. Дополнительные сведения см. в подразделе "Процесс использования резервных ресурсов" раздела Упаковка и развертывание ресурсов. Поэтому важно правильно установить ресурсы в глобальный кэш сборок. Вспомогательная сборка, скомпилированная со строгим именем, готова к установке в глобальный кэш сборок. Для установки сборок в кэш можно воспользоваться средством глобального кэша сборок (Gacutil.exe).
Следующая команда Gacutil.exe устанавливает сборку MyApp.resources.dll в глобальный кэш сборок.
gacutil /i:MyApp.resources.dll
Параметр /i указывает программе Gacutil.exe, что данную сборку требуется установить в глобальный кэш сборок. В результате выполнения этой команды в кэше появляется запись, разрешающая доступ к данным в указанном файле .resources. После установки в кэш ресурс становится доступен всем использующим его приложениям.
Каталоги вспомогательных сборок, не установленных в глобальный кэш сборок
После компиляции все вспомогательные сборки получают одинаковое имя. Среда выполнения различает сборки, основываясь на имени культуры, заданном при компиляции с помощью параметра Al.exe /culture, а также имени каталога, содержащего сборку. Вспомогательные сборки следует размещать в нужных каталогах.
На следующем рисунке показан пример структуры каталогов и приведены требования к размещению файлов для приложений, которые не устанавливаются в глобальный кэш сборок. Файлы с расширениями имен .txt и .resources не будут включаться в окончательный пакет приложения. Они представляют собой промежуточные файлы ресурсов, используемые для создания итоговых вспомогательных сборок ресурсов. В этом примере можно было бы заменить файлы .resx на файлы .txt. Файлы .resx — это единственный тип промежуточного файла ресурсов, который может включать объекты.
Каталог вспомогательной сборки
Примечание |
---|
Если приложение включает ресурсы для субкультур, каждой из них необходимо отвести отдельный каталог.Не следует размещать субкультуры в подкаталогах каталога основного языка и региональных параметров. |
См. также
Ссылки
Sn.exe (средство строгих имен)
Gacutil.exe (программа глобального кэша сборок)