|
Задачи развертывания в .NET Framework
За годы своего существования Windows получила репутацию нестабильной и
чрезмерно сложной ОС. Такая репутация, заслуженная или нет, сложилась по ряду
причин. Во-первых, все приложения используют динамически подключаемые
библиотеки (DLL), созданные Microsoft и другими производителями. Поскольку
приложение исполняет код, созданный разными производителями, ни один разработчик какой-либо части программы не может быть на 100% уверен в том, что
точно знает, как другие собираются применять созданный им код. Потенциально
такая ситуация чревата любыми неполадками, но на практике взаимодействие кодов
от разных производителей редко становится источником проблем, так как перед
развертыванием приложения тестируют и отлаживают.
Однако пользователи часто сталкиваются с проблемами, когда производитель
решает обновить поставленную им программу и передает им новые файлы. Предполагается, что новые файлы поддерживают «преемственную совместимость» с
прежними, но кто за это поручится? Одному производителю, выпускающему обновление своей программы, фактически не под силу заново протестировать и
отладить все существующие приложения, чтобы убедиться, что изменения при обновлении не влекут за собой нежелательных последствий.
Уверен, что каждый читающий эту книгу, встречался с той или иной разновидностью проблемы, когда новое приложение повредило какое-то из установленных ранее. Эта проблема получила название -ад DLL». Подобная уязвимость вселяет ужас в сердца и умы обычных пользователей компьютеров. Что до меня, то я
решил вовсе не пробовать некоторых приложений из опасения, что они нанесут
вред самым важным для меня программам.
Второй фактор, повлиявший на репутацию Windows, — сложности при установке приложений. Большинство приложений при установке не оставляют незатронутой ни одну из частей ОС. При установке приложения происходит, например, копирование файлов в разные каталоги, модификация параметров реестра,
установка ярлыков и ссылок на Рабочий стол, в меню Пуск и на панель быстрого
запуска. Проблема в том, что приложение — это не одиночная изолированная
сущность. Нельзя легко и просто создать резервную копию приложения, поскольку
кроме файлов приложения, для этого надо скопировать соответствующие части
реестра. Кроме того, нельзя просто взять и переместить приложение с одной
машины на другую — для этого придется запустить программу установки еще раз,
чтобы корректно скопировать все файлы и параметры реестра. Наконец, приложение не так просто удалить — обычно остается неприятное ощущение, что какая-то его часть все еще где-то таится.
Третья причина — безопасность. При установке приложений записывается
множество файлов, созданных самыми разными компаниями. Кроме того, многие так называемые «Web-приложения» часто сами загружают и устанавливают код
из Сети, о чем пользователю невдомек. На современном уровне технологий такой код может выполнять любые действия, включая удаление файлов и рассылку
электронной почты. Пользователи справедливо опасаются устанавливать новые
приложения из-за повреждений, которые они потенциально могут нанести их
компьютерам. Чтобы они чувствовали себя спокойнее, в системе должны быть
встроенные функции безопасности, позволяющие явно разрешать или запрещать
доступ к системным ресурсам коду, созданному теми или иными компаниями.
Как будет показано в этой и следующей главах, .NET Framework устраняет проблему «ада DLL» и делает существенный шаг вперед к решению проблемы, связанной
с разбросом сведений о состоянии приложения по всему жесткому диску. Так, в
отличие от СОМ компонентам больше не требуется хранить свои параметры в
реестре. К сожалению, приложениям пока еще требуются ссылки и ярлыки, но в
будущих версиях Windows и эта проблема, вероятно, будет снята. Усовершенствование безопасности связано с ноной моделью безопасности .NET Framework —
безопасностью доступа к коду (code access security). Если безопасность Windows
основана на идентификации пользователя, то безопасность доступа к коду — на
идентификации сборки. Так что пользователь может решать, доверять ли сборкам, опубликованным Microsoft, или вообще не доверять никаким сборкам, загруженным из Интернета. Как видите, .NET Framework предоставляет пользователям
намного больше возможностей по контролю над тем, что устанавливается и выполняется на их машинах, чем когда-либо давала им ОС Windows.
Предыдущая стр.
Оглавление
Следующая стр.
Средняя оценка:   (1 - 1 голосов)
Для оценки необходимо зарегистрироваться
Только зарегистрировавшиеся пользователи могут оставлять комментарии
|
|