Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Троелсен Э. -> "С# и платформа .NET. Библиотека программиста" -> 110

С# и платформа .NET. Библиотека программиста - Троелсен Э.

Троелсен Э. С# и платформа .NET. Библиотека программиста — СПб.: Питер, 2004. — 796 c.
ISBN 5-318-00750-3
Скачать (прямая ссылка): cplatforma2004.pdf
Предыдущая << 1 .. 104 105 106 107 108 109 < 110 > 111 112 113 114 115 116 .. 320 >> Следующая

* Почему так трудно работать с разными версиями двоичного файла СОМ?
* Почему установка двоичного файла СОМ на компьютере пользователя сопряжена с такими сложностями?
Надо сказать, что в все эти вопросы решаются гораздо проще. Причина заключается в том, что для двоичных файлов используется новый формат,
называемый сборкой (assembly). Однако прежде чем мы перейдем к рассмотрению архитектуры сборок, мы еще раз рассмотрим те проблемы, которые нам придется решать.
Проблема: работа с версиями СОМ
При работе с СОМ нам приходится создавать соклассы (coclasses) — пользовательские типы данных (то есть классы), реализующие интерфейсы СОМ (включая обязательный IUnknown). Затем сокласс упаковывается в двоичный файл DLL или ЕХЕ. После этого полученный двоичный файл развертывается на компьютере конечного пользователя и к нему могут обращаться другие программы.
Проблема, связанная с версиями СОМ, происходит из-за что в среде выполнения СОМ нет встроенного механизма, позволяющего гарантировать, что клиенту будет предоставлена нужная версия двоичного сервера СОМ. Конечно же, когда появляется новая версия сервера СОМ, мы ожидаем, что в ней будет реализована полная совместимость со старой версией. На практике же это происходит далеко не всегда.
Например, предположим, что на компьютере работает 10 приложений и при этом всем необходим MyCOMServer.dLl версии 1.4. Вдруг на компьютере устанавливается еще одно приложение, а вместе с ним — MyCOMServer.rJll версии 2.0. В результате вполне может получиться так, что все первые десять приложений разом перестанут работать. Такая ситуация не является такой уж редкостью, поскольку обеспечение полной обратной совместимости со старыми версиями — это исключительно сложная задача.
Ситуация, в которой необходимый программе модуль DLL может быть в любой момент перезаписан таким же модулем другой версии, получила название «ада DLL*- (DLL Hell). Она характерна не только для СОМ-серверов, но и для самых обычных DLL, написанных на С. Как мы убедимся в этой главе, в мире .NET «ада DLL» больше нет. Платформа .NET исключает саму возможность возникновения
Проблемы с классическими двоичными файлами СОМ 263
подобных ситуаций за счет реализации специальных технологий, таких как параллельное выполнение. Кроме того, в .NlIT реализована очень простая и надежная схема сосуществования разных версий двоичных файлов.
Проще говори, .NET разрешает одновременное размещение на клиентском компьютере (и одновременное ііьшонк !те1} разных версий одного и того же двоичного файла. Таким образом, если клиент А обратится к MyDotNETServer.dLl версии 1.4, а клиент В — к MyDotNETServer.dll версии 2.0, каждому из них будет предоставлена своя версия сервера. Привязка приложения к определенной версии двоичного файла может производиться при помощи файла конфигурации приложения.
Проблема: развертывание приложений СОМ
Взаимодействие со средой СОМ трудно назвать очень простой. Когда клиент СОМ
обращается к соклассу, первый его шаг состоит в загрузке библиотеки СОМ путем вызова Со in і f, IaI \zv<) для использования определенным потоком. Далее клиент
вызовы среде выполнения COM CoGetClassQbjectO и прочие) для загрузки этой библиотеки в память. В конечном итоге клиент СОМ получает ссылку на интерфеііс, которую можно использовать
для взаимодействия с соклассом.
Чтобы среда выполнения СОМ смогла обнаружить и загрузить двоичный файл СОМ-сервера, в первую очередь она должна знать, где физически этот файл лежит. Для этого СОМ-сервер должен быть правильно зарегистрирован. На первый взгляд регистрация не должна вызывать никаких сложностей: достаточно, чтобы программа установки или утилита, поставляемая с операционной системой, запу-стала необходимый кодвдвоичном файле СОМ-сервера (Di lRegisterServer() в DLL или WinMainO в EXE). При этом СОМ-сервер сам внесет в реестр все необходимые записи: самого класса COM (CLSID), интерфейса (IID), библиотеки (LIBID)1 приложения (ApplD) и прочие.
Проблема заключается в том, что многочисленные записи в относящи-
еся к СОМ-серверу, и сам двоичный файл СОМ-сервера никак физически не связаны между собой. За счет этого их взаимосвязь является очень хрупкой: достаточно конечному пользователю переместить двоичный файл СОМ-сервера в другое место или просто переименовать его, как множество приложений могут перестать работать.
Если мы используем модель распределенного СОМ, при котором СОМ-сервер может быть расположен на удаленном компьютере в сети, возникают свои сложности. Например, если к СОМ-серверу обращаются 100 клиентских компьютеров в сети, а сам двоичный файл лежит на каком-то сетевом сервере, то необходимые записи в реестр должны быть внесены на 101 компьютере. Естественно, в реальной работе при этом не избежать головной боли.
Плагформа упрощает развертывание приложений на клиентском компьютере за счет того, что записи о двоичных файлах (сборках) вообще не сятся в реестр. Вот так, просто и понятно. Вместо этого вся необходимая информация хранится в самих сборках. Все развертывание приложений .NET обычно сводится к копированию файлов на клиентский компьютер (или в общую папку на сервере). Прощай, HKEYJXASSESJKX)T I
Предыдущая << 1 .. 104 105 106 107 108 109 < 110 > 111 112 113 114 115 116 .. 320 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100