Программирование на Visual C++. Архив рассылки
Шрифт:
Концепция сборок предоставляет полную изолированность приложений (ну, почти полную). Сборки делятся на два типа:
• приватные (private) – те которые используются только самим приложением.
• совместные (shared) – те которые используются всеми.
Приватные сборки поставляются с самим приложением, используются только им и храниться в его папке. Microsoft рекомендует использовать совместные сборки только при крайней необходимости. Да, вы, конечно, можете сказать, что это нецелесообразно – с каждым приложение поставлять одни и те же сборки, можно ведь сделать сборку совместной, сэкономив тем самым немного места. Но на самом деле теперь, когда цена за мегабайт дискового пространства неуклонно уменьшается, а объем дисков неуклонно увеличивается, проблемы объема, занимаемого вашим приложением, не должны вас беспокоить. Собственно, здесь нужно выбирать между устойчивостью и небольшим увеличением эффективности
Приватные сборки видны только самому приложению и никому более, то есть приложение изолируется от внешнего воздействия как других программ, так и самой операционной системы. Соответственно, приватные сборки лишены многих проблем, связанных с совместными сборками. К примеру, такой, как уникальность имен: так как сборка приватна, нет необходимости заботится об уникальности имен во всем глобальном пространстве имен. Концепция приватных сборок сильно упрощает развёртывание (инсталляцию) ваших приложений, так как больше не придется делать записей в реестре, подобных тем, которые вы делали ранее для регистрации ваших COM-компонентов. Теперь вы будете просто копировать ваши сборки в директорию вашего приложения или в подчиненные директории. Общая среда исполнения (CLR) при запуске вашего приложения прочитает его манифест и определит, какие сборки необходимы. Затем будет произведён процесс зондирования (probing) (звучит прямо как зомбирование :) директории вашего приложения на предмет нужной сборки, сборка соответственно определяется по имени файла, определенного в манифесте.
ПРИМЕЧАНИЕ
Для справки: процесс зондирования (или зомбирования – это как кому больше нравится) – это просто рекурсивный поиск в директории вашего приложения (то есть при поиске сборки просматриваются все поддиректории).
Среда исполнения может подходить к зондированию достаточно интеллектуально: к примеру, могут быть выбраны локализованные для данного региона сборки, если, конечно, они поставляются автором приложения. Как выбираются именно нужные сборки, я расскажу позднее.
Как я говорил ранее, в манифесте сборки указывается строгая информация о версии. Но для приватных сборок точное соответствие версий не навязывается средой исполнения, так как считается, что разработчик имеет полный контроль над своим приложением и, соответственно, может сам управлять версиями, если это ему нужно.
Среда исполнения .NET поддерживает также совместные сборки. Это сборки, которые могут быть использованы сразу несколькими приложениями и которые, соответственно, "видны" всем. Правда, к таким сборкам предъявляются более строгие правила, к приватным сборкам. Например, необходима уникальность имен сборки: имена внутри сборки не должны конфликтовать с уже существующими в глобальном пространстве имен, предоставляемом средой исполнения по умолчанию, хотя система и предоставляет сервисы защиты имен (protection of the name). Специально для реализации этого сервиса была разработана технология Shared Names (совместные имена), описываемая далее.
Действия системы управления версиями при поиске необходимых сборок, могут быть изменены при помощи политики версий, которую сможет изменять администратор или приложения. Данная политика позволит принудительно изменить версию сборки, запрашиваемой приложением, а также поведение среды разработки при поиске и загрузке сборок. То есть приложение можно заставить использовать сборку другой версии, даже если оно на это не рассчитано. Данная политика настраивается при помощи файла конфигурации, который помещается в каталог приложения и имеет то же имя, что и у приложения, только с расширением .config. Подробно формат этих файлов я сейчас описывать не буду.
ПРИМЕЧАНИЕ
Тут может возникнуть вопрос: так где же она, изолированность? Ведь я тут вроде "распинался" о полной изолированности, можно сказать кричал, что все так круто, и вот тебе раз, оказывается, любой, кому нужно, сможет подменить версию, выглядит вроде нелогично, а может быть даже и абсурдно. Но давайте взглянем более детально, ведь политику надо задавать для определенного приложения с учетом его специфики, то есть просто как случайно изменить политику версий не удастся. Вот, вроде, всё и стало на свои места.
Совместные
сборки хранятся в глобальном кеше сборок (global assembly cache – GAC). Сборки, хранящиеся там, используются многими приложениями. К ним также имеет доступ администратор, который при необходимости сможет ставить патчи (Udgrade) на совместно используемые сборки, которые, соответственно, окажут влияние на все приложения, которые используют данные сборки. Для примера это может быть какая-нибудь заплатка на общие библиотеки среды, к примеру исправление в каком-нибудь классе. Реально хранилище сборок располагается в директории WinNt\assembly. Если вы ее будете просматривать при помощи проводника, вы увидите что-нибудь похожее на приведённый ниже рисунок.Рис. 3
Но на самом деле это не директория WinNt\Assembly. Когда вы открываете эту директорию, активизируется специальное расширение оболочки Windows и показывает вам сборки, которые сейчас хранятся в GAC. На самом же деле у хранилища, расположенного в этой директории, достаточно интересная структура. К примеру, у меня, она выглядит так:
Рис. 4
Структура этих директорий хотя и может показаться с первого взгляда очевидной, но на самом деле она очень хорошо продумана и спроектирована. Как вы уже могли заметить, в папке GAC есть подпапки, представляющие каждую сборку. Можно было бы подумать, что в них и будут храниться файлы с самими сборками, ан нет. Разработчики GAC поступили куда дальновиднее, в каждой папке, представляющей сборку хранятся подпапки, разбивающие данную сборку по версиям. Таким образом, у нас может храниться любое количество версий одной и той же сборки. Зачем же, спрашивается, это нужно? Ведь такой подход никак ни способствует экономии места на диске. Все на самом деле проще, чем вы могли подумать. Как я уже говорил ранее, Microsoft стремилась сделать приложения как можно более стабильными и даже пошла ради этого на жертву в виде вашего дискового пространства. При таком подходе каждое приложение сможет использовать именно ту совместную сборку, на которую оно рассчитано. То есть при загрузке приложения для него будет выбираться сборка именно той версии, которую он запросит, хотя может существовать и гораздо более новая версия этой же сборки.
ПРИМЕЧАНИЕ
Хотя здесь надо оговориться: к любому приложению может быть применена политика версий, которая принудительно его заставит использовать указанную в политике сборку.
Поиск в глобальном хранилище сборок идет, основываясь на строгих сведениях о версии, что позволяет избегать многих проблем, описанных ранее. Для повышения надежности и стойкости системы GAC, вы не сможете производить какие либо действия (кроме, конечно, простого просмотра) с глобальным хранилищем, если вы не будете иметь прав администратора. Такая политика введена по умолчанию в отношении GAC, хотя при желании ее можно будет изменить. А что это вообще означает? Тут, на самом деле, все интереснее, чем могло бы показаться с первого взгляда. Смысл данной политики таков: пользователь, не имеющий прав администратора, не сможет как-либо повлиять на работу приложений, установленных в системе, хотя и сможет устанавливать приложения, но лишь те, которые не будут использовать совместных сборок. Иными словами, ничего глобального простому пользователю испортить не удастся.
Сама версия состоит из четырёх чисел; для наглядности, пожалуй, даже нарисую.
Рис. 5
На практике это выглядит, к примеру, так: 1.0.2.3. Где:
• Major – основная версия.
• Minor – подверсия приложения.
• Build – количество построений (полных компиляций) для данной версии.
• Revision – Номер ревизии для текущего построения.
В версии выделяется основная часть и дополнительная. При поиске нужной сборки, основная часть версии должна строго совпадать, а с дополнительной частью всё происходит хитрее. Если будет найдено несколько сборок с одинаковыми основными частями, то будет выбрана сборка с наибольшей дополнительной частью. Версию сборки вы можете задать при помощи параметра командной строки либо при помощи атрибута System.Reflection.AssemblyVersionAttribute. Здесь, правда, есть одна хитрость: вы можете задавать версию не полностью, а только ее часть. К примеру вот так: "1.*","1.5.*,@1.5.2.*". При отсутствии каких либо частей, компилятор допишет их сам по следующим правилам: