Принципы работы СОМ
В завершение мы решили остановиться на проблемах установки и размещения программ, а также на использовании готовых программ, использующих модель COM (Component Object Model). Вообще-то на эту тему можно написать целую книгу, но мы надеемся, что это короткое вступление поможет вам перейти к самостоятельному изучению этой темы.
Установка большинства приложений .NET сводится к простому копированию каталога, содержащего необходимые файлы, на любой компьютер с установленной исполнительной средой .NET. Программа запускается двойным щелчком на имени ЕХЕ-файла в окне Проводника (Windows Explorer).
Примечание
Выбирая значок Setup and Deployment Project в диалоговом окне New Project, вы получите доступ к весьма нетривиальным возможностям установки. Мастер Setup Wizard чрезвычайно прост в использовании, но для большинства стандартных ситуаций его возможностей оказывается вполне достаточно.
Тем не менее даже в .NET иногда встречаются ситуации, когда простое копирование не подходит, а программа-мастер слишком ограничивает вашу свободу действий. Чтобы разобраться в принципах установки приложений .NET, необходимо знать, как работают сборки (assemblies), поскольку приложения .NET распространяются в виде сборок.
Во многих устанавливаемых приложениях хотя бы часть работы выполняется традиционными объектами СОМ, поэтому в этой главе будут кратко затронуты вопросы использования объектов СОМ в .NET [И наоборот – объекты .NET могут использоваться в СОМ, однако эта возможность выглядит несколько экзотически.]. А поскольку одной из целей разработки .NET было исправление недостатков СОМ, мы начнем с краткого обзора СОМ и основных проблем, связанных с этой технологией.
Технология СОМ упрощает создание программ, сохраняющих совместимость в разных версиях платформы Windows и более или менее независимых от языка программирования. Компоненты СОМ могут создаваться на разных языках, включая классический С (вариант для мазохистов), C++, Delphi, VB5 и 6. Технология СОМ с большим успехом применялась для создания объектов, предназначенных для решения специализированных задач, таких как элементы VB OCX.
Технология СОМ была задумана как механизм, при помощи которого программные компоненты получают информацию о возможностях других компонентов и обращаются к ним с запросами, не беспокоясь о подробностях внутренней реализации [Существуют и другие технологии, ориентированные на повторное использование программного кода (например, CORBA), но пока наибольшего успеха добилась именно модель СОМ.]. Для этого был выработан стандартный протокол получения информации об интерфейсах, поддерживаемых другими компонентами, наряду со стандартизацией средств для обращения к конкретной реализации интерфейса в экземплярах.
Тем не менее у СОМ были свои недостатки. Во-первых, реализация СОМ для Windows требовала, чтобы в системном реестре хранилась вся информация обо всех компонентах в системе. Пользователю приходилось регистрировать компоненты при установке программ и стирать соответствующую информацию при удалении программ. При попытке удаления программ возникала опасность того, что изменения, внесенные в реестр, повлияют на работу других программ. Стоило серьезно повредить реестр, и система вообще переставала работать. Более того, установка новой версии компонента нередко нарушала работу программ, рассчитанных на более раннюю версию компонента.
Примечание
В Windows 98 была впервые представлена концепция параллельного выполнения (side-by-side execution); это означало, что приложение могло использовать локальный экземпляр компонента СОМ, находящийся в каталоге приложения, вместо экземпляра, зарегистрированного в системе. Справедливости ради следует сказать, что параллельное выполнение так и не решило проблемы с "кошмаром DLL", вдобавок оно работает только в Windows 98, 2000 и ХР – и то если об этом специально позаботится разработчик программы.
Давайте посмотрим, что происходит на уровне реестра при регистрации компонентов СОМ.
- Разработчик создает для компонента глобально-уникальный идентификатор (GUID).
- Разработчик создает для компонента программный идентификатор (ProgID).
- Утилита регистрации связывает ProgID компонента с GUID, создавая соответствующую запись в реестре.
- Утилита регистрации заносит полный путь к двоичному файлу компонента в реестр и связывает его с GUID компонента.
- Утилита регистрации также может сохранить в реестре дополнительные сведения о компоненте – например, тип потоковой модели.
При попытке использования компонента происходит следующее:
- Разработчик приложения создает экземпляр компонента, используя ProgID.
- СОМ ищет в реестре GUID компонента.
- СОМ находит двоичный файл компонента.
- СОМ создает экземпляр компонента.
Несмотря на большое количество выполняемых операций, главные проблемы возникают при копировании в систему нового файла с компонентом, не сопровождающимся обновлением реестра, и при смене GUID. Приложение, которое раньше благополучно работало, работать перестает. Это связано с тем, что в механизме установки СОМ не предусмотрено нормальных средств для контроля версии компонентов.