Microsoft .NET Framework FAQ - Сборки

 

Сборки

Что такое сборка?

Сборка - это базовый строительный блок приложения в .NET Framework. Это набор функциональности, которая создается, развивается и развертывается, как единый модуль (при этом он может содержаться в одном или нескольких файлах). Все управляемые типы и ресурсы помечаются либо как доступные только внутри сборки, либо как доступные вне модуля.
Составной частью сборки является декларация, которая позволяет сборке быть самоописанной. Декларация идентифицирует сборку (в виде текстового имени), версию, культуру и цифровую сигнатуру(если сборка разделяется среди приложений).

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

Эта информация используется в период выполнения, чтобы разрешить ссылки, обеспечить корректное использование версий, проверить целостность загруженных сборок. Среда выполнения может определить сборку для любого запущенного объекта, поскольку любой тип используется только в контексте сборки. Сборки также являются модулями, для которых применяются проверки безопасности доступа кода. Идентификация производится для каждой сборки поотдельности, чтобы определить, какие права можно предоставить коду, который она содержит.

Самоописываемая природа сборок позволяет реализовать безболезненную инсталляцию и развертывание, через XCOPY.

Что такое приватные сборки и совместно используемые сборки?

Приватные сборки используются только одним приложением, и они хранятся в директории, в которой установлено приложение или ее поддиректории. Совместно используемые сборки могут быть использованы несколькими приложениями. Чтобы предоставить сборку в совместное использование, необходимо дать сборке уникальное шифрованное "строгое имя". В отличии от совместно используемой сборки, имя приватной сборки должно быть уникально только в рамках приложения.

Вводя разделение между приватными и совместно используемыми сборками, мы делаем понятие совместного использования осознанным решением. Просто разместив приватную сборку в директорию приложения, вы будуте уверены в том, что эта сборка будет работать только в этом приложении. Ссылки на приватные сборки разрешены только локально, в рамках приложения.

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

Для локально устанавливаемых приложений, совместно используемые сборки обычно устанавливаются в глобальный кэш сборок. Ключевой особенностью системы управления версиями .NET Framework является то, что загруженный код не влияет на выполнение локально установленных приложений. Загруженный (с Интернета или Интранета) код размещается в специальный кэш загрузки и не доступен глобально на машине, даже если определенные из компонент помечены как совместно используемые сборки.

Классы, которые включены в состав .NET Framework являются совместно используемыми сборками.

Если я хочу создать совместно используемую сборку, требует ли это работы с подписями и парами ключей?

Создание совместно используемой сборки включает работу с ключами шифрации. Для построения сборки обязательно необходим только публичный ключ. Компиляторы, входящие в .NET Framework, имеют набор аргументов в командной строке, которые позволяют указать публичный ключ при создании сборки. Обычно копию ключа хранят вместе с исходниками и указывают, что при сборке использовать данный ключ. Перед передачей сборки, она должна быть полностью подписана, с соответствующим приватным ключом. Это делается с использованием утилиты SN.EXE, входящей в состав SDK.

Подписи строгих имен не включают сертификаты, как например, делает Authenticode. Нет необходимости подключать сторонние огранизации, не нужно дополнительных плат и сертификатов. Кроме того, накладные расходы для проверки строгого имени значительно меньше, чем в Authenticode. Однако при работе со строгими именами не делается никаких проверок о доверии определенному издателю. Строгие имена позволяют вам быть уверенными, что содержимое сборки не изменено и что загруженная сборка получена от того же производителя. Но не делается никаких предположений относительно того, можете ли вы доверять данному издателю.

В чем отличие между пространством имен и именем сборки?

Пространство имен - это логическая схема именования типов, в которой простому имени типа, например, МойТип, предшествует разделенное точками иерархическое имя. Такая схема именования находится полностью под контролем разработчика. Например, по имени типов МояКомпания.ФайловыйДоступ.А и МояКомпания.ФайловыйДоступ.В можно ожидать, что их функциональность имеет отношение к работе с файлами. .NET Framework использует иерархическую схему именования типов для объединения типов в логические категории с общей функциональностью. Средства разработки позволяют удобно просматривать типы, ссылаться на них и использовать в коде. Концепция пространства имен не имеет прямого отношения к сборке. Одна сборка может содержать типы, имена которых начинаются в разных пространствах имен, и одно пространство имен может быть реализовано в нескольких сборках. В .NET Framework пространство имен является соглашением по именовании в процессе разработки, в то время как сборка устанавливает область действия имени для типа в период выполнения.