Программирование на Visual C++. Архив рассылки
Шрифт:
Программирование на Visual C++
Выпуск №60 от 20 января 2002 г.
Здравствуйте, дорогие подписчики!
Рад снова вас приветствовать на страницах рассылки.
Эх, меняются времена. Сейчас объем статей становится настолько большим, что они редко просто влезают в ограниченный 60 килобайтами выпуск без разбивания на две части. А когда все-таки влезают, то ни для чего другого места больше не остается ;-) Но я думаю, хорошие статьи все-таки для читателей важнее. Сегодня я предлагаю вам познакомиться с очередной концепцией новой платформы .NET – т.н. сборками.
СТАТЬЯ
Немного о сборках
Автор:
Source.zip – 1.3 KB
При проектировании платформы .NET одной из задач являлось легкое развёртывание (инсталляция) и поддержка приложений, так как в настоящее время эта проблема стала серьезно беспокоить не только разработчиков, но и рядовых пользователей. Наверное, каждый знаком с ситуацией, когда после установки новой программы некоторые старые приложения наотрез отказывались работать. Ниже я вам поведаю о том, какое решение данной проблемы предоставила Microsoft на этот раз.
Все началось очень давно, когда Microsoft еще только задумывалась над идеей повторного использования кода. В те времена для решения данной проблемы были созданы динамически подгружаемые библиотеки (Dynamic-Link Load Library, DLL). Они позволяли "выносить" часто используемый код в отдельные библиотеки, которые могли использовать любые приложения. Проблема была в том, что DLL изначально не предоставляли никаких средств управлениям версиями, тогда об этом просто никто не задумывался. Впоследствии Microsoft ввела Version Info (информацию о версии), которая помещалась в DLL как ресурс. Но это не решало проблему полностью, а лишь позволяло определять версию библиотеки, то есть отчасти гарантировало, что будет использоваться именно нужная библиотека. И никак не разъясняло вопрос о том, что делать, если версия библиотеки не совпадает с требуемой. К тому же, вся поддержка версий ложилась на плечи программиста. Для того чтобы корректно поддерживать старые версии, приходилось в уже новых библиотеках оставлять все старые функции, которые и поныне используются старыми приложениями. К примеру, в так называемом ядре Windows – библиотеке Kernel32.dll (которая, по сути, ядром-то и не является), присутствуют многие устаревшие функции, которые в настоящее время используются только устаревшими приложениями, но оставлены для совместимости (WinExec и др.).
ПРИМЕЧАНИЕ
Вы сможете найти список всех таких функций в Platform SDK на странице Obsolete Windows Programming Elements.
Из-за таких функций в последствии сильно затрудняется разработка, так как их количество растет, подобно снежному кому, от версии к версии. Причём не все разработчики добросовестно поддерживают старые версии, чего, кстати, нельзя сказать о Microsoft. Из-за этого и возникают проблемы, похожие на ту, что описана в начале статьи. Представьте, что старая библиотека будет заменена новой, пусть даже и лучшей, но не поддерживающей старые функции. Старое приложение, рассчитанное на старую версию библиотеки, не найдя нужных ему функций, попросту завершит свою работу (собственно и не начиная её).
Вторым шагом было создание COM, который уже предусматривал поддержу версий как неотъемлемую свою часть. Вся поддержка версий в COM в основном основывалась на регистрации приложений и компонентов COM в системном реестре. Что, как позже выяснилось, было далеко не гениальным решением. Поддержка совместимости версий все еще была возложена на плечи разработчика, что само по себе не подразумевало решения проблемы. Ведь что взбредет в голову простому разработчику – одному господу богу известно. Захочет он поддерживать старые версии, или нет, – это его личный выбор. От которого, кстати, будут очень зависеть
При проектировании .NET была поставлена задача разработать технологию, которая позволила бы решить проблему версий, быстрого развёртывания и изоляции приложений. В основу новой технологии легли сборки (Assembly), которые призваны решить обозначенные выше проблемы.
• Сборки – это наименьшие строительные блоки, на которых базируется платформа .NET.
• Различия в версиях могут существовать только на уровне сборок; предполагается, что внутри сборки никакие элементы (классы, интерфейсы и т. п.) не могут иметь собственные версии.
• Сборки являются хранилищами как для кода, так и для ресурсов.
• Сборки самоописываемы – они содержат метаданные (metadata), которые несут в себе информацию о версии, зависимостях, типах, атрибутах и многое другое.
• Сборки защищены – система защиты исполняемого кода использует права запуска индивидуально для каждой сборки. Автором сборки в метаданных записываются права на использование данной сборки кем бы то ни было, что позволяет защищать код "родными" для системы методами, не прибегая к продуктам сторонних производителей.
Манифест – это метаданные, включающие информацию о сборке, а именно:
• Данные о версии – версию, имя и необязательные данные.
• Список файлов – имена файлов, составляющих сборку, а также их контрольные суммы, вычисляющиеся при помощи криптографических хэш-функций во время создания сборки. Во время выполнения данные файлы проверяются по контрольным суммам, чтобы удостоверится в целостности данного файла, а так же в том, что файл не был подменён другим с таким же именем или просто его новой версией.
• Зависимости от других сборок – имена и версии сборок, которые используются данной сборкой. Во время выполнения версии сборок строго сверяются, чтобы удостовериться в том, что загружена именно нужная сборка.
• Экспортируемые типы и ресурсы. Видимость для этих объектов может быть двух типов: только для моей сборки (internal) и для всех (public), включая внешние запросы.
• Свойства защиты. Здесь можно выделить три типа:
• Права на запуск данной сборки.
• Некоторые возможности сборки будут недоступны, если она не лицензирована.
• Сборка должна запускаться только в том случае, если она лицензирована.
ПРИМЕЧАНИЕ
Список файлов, из которых состоит сборка, и зависимости от других сборок – это совершенно разные вещи. Сборка сама по себе может быть разбита на несколько файлов, хотя для тех, кто ее использует, она будет выглядеть как единое целое. То есть, к примеру, общие классы могут лежать в одном файле, ресурсы – в другом, специальные классы – в третьем файле и так далее. Для чего, спрашивается, это нужно? Во-первых, это нужно для гибкой загрузки распределенных приложений, так как файлы, составляющие сборку, могут загружаться по мере необходимости, а не все сразу. Во-вторых, для создания распределённых приложений, так как местоположение файлов не играет никакой роли: файлы из одной и той же сборки могут находиться где угодно: в Интернете, на сетевых дисках и так далее.