Программирование на Visual C++. Архив рассылки - Алекс Jenter

ПРИМЕЧАНИЕ

Тут может возникнуть вопрос: так где же она, изолированность? Ведь я тут вроде "распинался" о полной изолированности, можно сказать кричал, что все так круто, и вот тебе раз, оказывается, любой, кому нужно, сможет подменить версию, выглядит вроде нелогично, а может быть даже и абсурдно. Но давайте взглянем более детально, ведь политику надо задавать для определенного приложения с учетом его специфики, то есть просто как случайно изменить политику версий не удастся. Вот, вроде, всё и стало на свои места.

Совместные сборки хранятся в глобальном кеше сборок (global assembly cache – GAC). Сборки, хранящиеся там, используются многими приложениями. К ним также имеет доступ администратор, который при необходимости сможет ставить патчи (Udgrade) на совместно используемые сборки, которые, соответственно, окажут влияние на все приложения, которые используют данные сборки. Для примера это может быть какая-нибудь заплатка на общие библиотеки среды, к примеру исправление в каком-нибудь классе. Реально хранилище сборок располагается в директории WinNtassembly. Если вы ее будете просматривать при помощи проводника, вы увидите что-нибудь похожее на приведённый ниже рисунок.

Рис. 3

Но на самом деле это не директория WinNtAssembly. Когда вы открываете эту директорию, активизируется специальное расширение оболочки 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.*". При отсутствии каких либо частей, компилятор допишет их сам по следующим правилам:

• Minor – приравнивается к нулю

• Build – приравнивается количеству дней прошедших с первого января 2000 года

• Revision – приравнивается количеству секунд, прошедших с полуночи, деленных на два.

Такая, казалось бы, странная схемы выбрана далеко не случайно: она позволяет гарантировать уникальность версии для каждого построения приложения, что, вообщем-то, немаловажно.

Я долго думал, как на словах описать эту технологию, но что-то ничего не лезло в голову, поэтому я решил нарисовать. Думаю, что, посмотрев на рисунок, вы сразу многое поймёте. Главное, обратите внимание на версии.

Рис. 6

Идея состоит в том, что для одного и того же приложения могут быть загружены разные версии одной и той же сборки, и при этом оно ничего не будет знать об этом. Для примера, библиотеки, обозначенные на рисунке цифрами 1 и 2, будут загружены для нашего приложения и может даже будут одновременно работать, но ни одна из них не узнает о существовании другой, что позволит избежать каких-либо конфликтов.

ПРЕДУПРЕЖДЕНИЕ

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

Допустим, что среда выполнения (CLR) при загрузке приложения нашла требуемую сборку с подходящей версией. По идее, надо начать ее загружать, но возникает вопрос: а как узнать, что это действительно именно та сборка, которая нам нужна, а не другая. Ведь возможно, что кто-то захочет выдать свою сборку за чужую, или нужная сборка оказалась поврежденной, скажем, при передачи по сети. COM, к примеру, не предусматривал решения этой проблемы. В .NET для решения данного вопроса используются односторонние хэш-функции, в простонародье называемые контрольными суммами. В дополнении к информации об используемой сборке, во время компиляции считается контрольная сумма используемой сборки и помещается вместе с информацией о версии. Во время загрузки проверяется контрольная сумма, и на основание этой проверки будет вынесет вердикт о валидности сборки. По умолчанию используется хэш-функция SHA1. Плюс еще используется технология подписывания (signing) сборок, основанная на открытых криптографических алгоритмах с парными ключами. Вообще, ребята из Microsoft здорово поработали над этой проблемой. Ими было применено очень много интересных решений, о которых я, возможно, расскажу в отдельной статье.

Для простого развертывания приложений были существенно расширены сервисы, предоставляемые Windows Installer. Теперь он полностью поддерживает .NET. Создание инсталляций станет более простым, так как теперь данная возможность интегрирована в стандартную поставку среды разработки .NET. То есть вы сможете использовать все современные сервисы, предоставляемые Windows Installer, в ваших приложениях, не прибегая к средствам сторонних производителей. А предоставляет он их, кстати, не мало, но об этом в отдельной статье.