PHP и IIS, пример работы с базой данных
Network Address Translation (NAT)
Защита локальных сетейПри соединении локальной сети с Интернет, необходимо надежно защитить локальную сеть и сервер. Обеспечить защиту сетей может, так называемый, межсетевой экран - firewall | брандмауэр. Из-за несовершенства защиты firewall для Windows, сеть без брандмауэра становится открыта для несанкционированного доступа извне. Firewall, установленный на шлюзе, защищает всю сеть сразу, заметно облегчая работу администратора. Что такое брандмауэрБрандмауэр (межсетевой экран | фаервол | firewall) - это специализированное программное средство, которое осуществляет контроль и фильтрацию сетевых пакетов на основе набора правил. Правила могут задавать критерии фильтрации на различных уровнях модели OSI, чаще всего - это сетевой и/или прикладной уровни. Брандмауэр предназначен для защиты отдельных компьютеров и целых локальных сетей от несанкционированного доступа злоумышленников, а также для фильтрации доступа к определенным ресурсам в сетях (например, Интернет). Фильтры сетевого трафика определяют, какие пакеты попадут к источнику от назначения, а какие будут отброшены. При блокировке пакета, брандмауэр может отправить источнику пакета специальное ICMP-сообщение о том, что его запрос был запрещен. Если Firewall нестроен просто отбрасывать сетевой пакет, то для источника хост с адресом назначения будет невидим. Иногда режим работы, при котором настройки firewall на хосте указывают отбрасывать все пакеты, направленные к нему для инициации соединения, называют stealth-режим. Сетевой FirewallСетевой Firewall (межсетевой экран) устанавливается на шлюзе, соединяющем несколько подсетей, и выполняет фильтрацию потока данных на сетевом уровне. Сетевой Firewall зачастую обладает функцией трансляции адресов (NAT), позволяющей вести работу подсетей от одного внешнего адреса шлюза. Firewall уровня приложенийПерсональный Firewall устанавливается на пользовательском компьютере и предназначен для защиты от несанкционированного доступа только этого компьютера. Зачастую, персональный Firewall подразумевает фильтрацию сетевой активности приложений и это является его основной функцией. Контроль данных на сетевом уровне также возможен, однако из-за невысоких знаний пользователей используется редко. Также, персональный Firewall обычно поставляется как комплексное решение и содержит в себе антивирус, антиспам, IDS-систему, фильтр контента и т.д. |
Обычно для подключения локальной сети к Интернету через Интернет шлюз используется один или несколько внешних IP-адресов, а компьютерам локальной сети присваиваются внутренние IP-адреса.
Существует несколько причин такого способа подключения:
Для подключения локальной сети к Интернет существует несколько способов. Самые популярные из которых - использование в качестве Интернет шлюза proxy сервера и NAT сервера. Proxy сервер работает на уровне приложений, а драйвер NAT - на уровне стека протоколов TCP/IP.
Главные минусы использования proxy сервера - необходимость настройки каждого клиентского приложения, несовместимость некоторых приложений с работой через proxy сервер (например, банковские программы, игры), очень низкая производительность и высокое потребление системных ресурсов Интернет сервера.
Использование NAT обеспечивает прозрачность для приложений - их не нужно настраивать, с NAT работают практически все протоколы и приложения. Поскольку NAT представляет собой низкоуровневый сетевой драйвер, то его производительность по сравнению с proxy серверами выше в несколько раз. Соотвтетственно выше скорость работы Интернет сервера.
В отличие от множества других программных решений, использующих встроенный в Windows драйвер NAT, в Lan2net NAT Firewall используется более производительный драйвер NAT собственной разработки.
Для построения локальных сетей необходимо использовать специально определенные в RFC 1918 группы приватных IP-адресов:
Иногда диапазоны этих IP-адресов также называют частные или серые IP-адреса. Внешние реальные адреса имеют название белые IP-адреса. Таким образом, компьютерам локальной сети могут назначаться IP-адреса из указанных диапазонов. Однако, непосредственный доступ в Интернет из таких сетей невозможен.
Для подключения всей локальной сети достаточно иметь единственный узел с доступом в Интернет, имеющий уникальный белый IP-адрес. Такой узел называется Интернет шлюзом или Интернет сервером. Интернет шлюз должен иметь, как минимум, два сетевых адаптера. Один из которых обеспечивает доступ в Интернет. Этому внешнему адаптеру присвоен белый IP-адрес. Внутренним адаптерам могут быть присвоены как белые, так и серые IP-адреса.
При прохождении сетевых пакетов через Интернет сервер, с внутреннего адаптера на внешний и обратно, происходит трансляция сетевых адресов (NAT). Такой механизм обеспечивает прозрачный доступ в Интернет для узлов с серыми IP-адресами. Кроме того, все соединения после шлюза выглядят так, как если бы они были установлены с единственного белого IP-адреса. Тем самым обеспечивается сокрытие конфиденциальной информации о локальной сети.
В программном комплексе Lan2net NAT Firewall трансляция сетевых адресов выполняется для протоколов: TCP, UDP и ICMP.
Трансляция сетевых адресов выполняется в процессе контроля транзитных соединений на Интернет сервере. Когда пакет IP-соединения с серым IP-адресом источника передается драйвером внутреннего сетевого адаптера к драйверу стека TCP/IP, сетевой драйвер Lan2net NAT Firewall перехватывает пакет, изменяя в нем IP-адрес источника и номер порта источника для протоколов UDP и TCP. Для пакетов протокола ICMP модифицируется идентификатор запроса. После модификации пакета он передается драйверу внешнего сетевого адаптера Интернет шлюза и далее отсылается необходимому узлу в Интернет.
При передаче в сеть Интернет пакет выглядит так, как будто, он отправлен с белого внешнего IP-адреса. Тем самым обеспечивается уникальность IP-адреса источника соединения в рамках всей сети Интернет.
Получив ответные пакеты, драйвер внешнего сетевого адаптера передает их драйверу стека TCP/IP. В этот момент пакеты перехватываются драйвером Lan2net NAT Firewall. Сетевой драйвер Lan2net NAT Firewall определяет принадлежность пакетов исходному IP-соединению. Так как при модификации номеров TCP-, UDP-портов или идентификатора ICMP-запроса в исходящих пакетах им были присвоены уникальные значения, то теперь на основе этих значений драйвер может восстановить оригинальный, серый IP-адрес источника запроса.
Таким образом, в ответных пакетах IP-адрес назначения заменяется на IP-адрес источника запроса, а номера TCP-, UDP-портов или идентификатора ICMP-запроса также восстанавливают свои оригинальные значения. После этого ответные пакеты передаются драйверу TCP/IP и далее, через внутренний адаптер, к узлу, сделавшему запрос.
DNS ForwarderDNS Forwarder выполняет функцию перенаправления DNS-запросов от клиентов в локальной сети к вышестоящим DNS-серверам. Основными предназначениями DNS Forwarder являются централизация и автоматизация управления конфигурацией локальной сети, а также, при наличие возможности кэширования DNS-запросов - снижение нагрузки на вышестоящие DNS-сервера. |
Реализованный в Lan2net NAT Firewall DNS Forwarder, позволяет обеспечить бесперебойную работу DNS-службы при наличие нескольких вышестоящих DNS-серверов. Все сервера задаются в программе в виде упорядоченного списка или автоматически загружаются из системных настроек.
Если активный DNS-сервер перестает функционировать, будет выполнен автоматический переход на работу со следующим активным DNS-сервером из списка. При достижении последнего сервера в списке будет выполнен переход на первую запись. Изменение активного DNS-сервера происходит только при сбоях в работе текущего сервера. Отслеживание восстановления работы отказавшего сервера не производится.
Для корректной и стабильной работы компонента DNS Forwarder необходимо отсутствие на компьютере сервисов, использующих для своей работы порт 53 по протоколам UDP и TCP.
http://www.lan2net.ru/l2n_config.shtml
Введение в Microsoft .NET для начинающих
Не имея четкого представления о
Microsoft .NET и роли, которую играет в
этой новой инициативе Microsoft язык С#,
вам будет трудно разобраться в
ключевых элементах С#,
поддерживаемых платформой Microsoft .NET.
Представленный в этой главе обзор
технологии Microsoft .NET поможет вам
усвоить терминологию, применяемую
в этой книге, и понять, почему
некоторые элементы языка С# ведут
себя так, а не иначе. Если
просмотреть в Интернете материалы
по Microsoft .NET, можно заметить разнобой
в трактовке и употреблении
терминов этой технологии.
Двусмысленные, а порой и просто
противоречивые высказывания
мешают уловить суть излагаемого
материала. Во многом это
объясняется новизной проблемы.
Поэтому первым делом я постараюсь
разогнать туман вокруг этой темы и
разъяснить некоторые термины,
связанные с Microsoft .NET.
Не имея четкого представления о
Microsoft .NET и роли, которую играет в
этой новой инициативе Microsoft язык С#,
вам будет трудно разобраться в
ключевых элементах С#,
поддерживаемых платформой Microsoft .NET.
Представленный в этой главе обзор
технологии Microsoft .NET поможет вам
усвоить терминологию, применяемую
в этой книге, и понять, почему
некоторые элементы языка С# ведут
себя так, а не иначе. Если
просмотреть в Интернете материалы
по Microsoft .NET, можно заметить разнобой
в трактовке и употреблении
терминов этой технологии.
Двусмысленные, а порой и просто
противоречивые высказывания
мешают уловить суть излагаемого
материала. Во многом это
объясняется новизной проблемы.
Поэтому первым делом я постараюсь
разогнать туман вокруг этой темы и
разъяснить некоторые термины,
связанные с Microsoft .NET.
Платформа Microsoft .NET
Идея Microsoft .NET в том, чтобы переместить центр внимания вычислительного сообщества из мира, состоящего из различных устройств и Web-узлов, связанных между собой через Интернет, в мир, где высокое качество решений для пользователей обеспечивается совместной работой устройств, служб и компьютеров. Основу Microsoft .NET составляют четыре базовых компонента:
Большинство разработчиков воспринимает инфраструктуру .NET собственно как .NET. Поэтому в дальнейшем при любом упоминании .NET (если нет предварительной оговорки) я буду иметь в виду инфраструктуру .NET. Инфраструктура .NET связана со всеми технологиями, составляющими новую среду создания и выполнения надежных, масштабируемых, распределенных приложений. Та часть .NET, с помощью которой разрабатываются такие приложения, называется .NET Framework.
NET Framework состоит из Common Language Runtime
(CLR) и набора библиотек классов .NET
Framework, который иногда называют Base
Class Library (BCL). CLR — это по сути
виртуальная машина, в которой
функционируют приложения .NET. Все
языки .NET имеют в своем распоряжении
библиотеки классов .NET Framework. Если вы
знакомы с Microsoft Foundation Classes (MFC) или
Object Windows Library (OWL) компании Borland, то
вам не надо объяснять, что это
такое. Библиотеки классов .NET Framework
включают поддержку практически
всех технологий от файлового
ввода-вывода и обмена с БД до XML и SOAP.
Вообще библиотеки классов .NET Framework
столь обширны, что даже
поверхностный обзор всех
поддерживаемых классов потребует
отдельной книги.
Замечу, что под термином
"виртуальная машина" здесь не
подразумевается Java Virtual Machine (JVM).
Фактически я применяю этот термин в
его традиционном значении.
Несколько десятилетий назад, когда
Java значило лишь темный, горячий
напиток, IBM ввела в оборот
словосочетание "виртуальная
машина" ("virtual machine"). Этим
странным словосочетанием была
обозначена абстракция
высокоуровневой ОС, внутри которой
могли функционировать в полностью
инкапсулированной среде другие ОС.
Говоря о CLR как о виртуальной
машине, я имею в виду то, что код,
выполняемый в инкапсулированной и
управляемой среде, отделен от
других процессов на этой машине.
.NET Framework
Что же представляет собой .NET Framework
и что он дает? Вначале мы сравним .NET
с другой более ранней средой
разработки распределенных
приложений. Затем я перечислю
возможности .NET, позволяющие
создавать мощные распределенные
приложения в сжатые сроки.
Windows DMA и. NET
Фраза, которой я охарактеризовал
.NET: "новая среда для создания и
запуска надежных, масштабируемых,
распределенных приложений" —
звучит знакомо, да? Дело в том, что
.NET является продолжением
предыдущей попытки достичь этой
цели. Та платформа называлась Windows
DNA. Однако перспектив у .NET по
сравнению с Windows DNA несопоставимо
больше. Платформа Windows DNA была
нацелена на решения для бизнеса
посредством серверных продуктов
Microsoft. К Windows DNA порой применяли
слово "клей" в таком, например,
контексте: "DNA — это клей, с
помощью которого соединяются
надежные, масштабируемые,
распределенные системы". Однако,
будучи только технической
спецификацией, Windows DNA не имело
каких-то осязаемых компонентов. Это
только одно из ряда основных
различий между Windows DNA и .NET. В Microsoft
.NET, кроме набора спецификаций,
входит несколько реальных
продуктов: компиляторы, библиотеки
классов и даже целые приложения для
конечных пользователей.
Common Language Runtime
Common Language Runtime (CLR) — это сердце
технологии Microsoft .NET. Как следует из
названия, это среда времени
выполнения кода, в которой
обеспечивается эффективное
взаимодействие приложений,
пересекающее границы разных языков
программирования (cross-language
interoperability). Как достигается это
взаимодействие? Common Language Specification (CLS)
— это набор правил, которых должен
придерживаться компилятор языка
при создании .NET-приложений,
запускаемых в среде CLR. Любой, кто
захочет написать компилятор для .NET,
должен следовать этим правилам и —
пожалуйста! — приложения,
сгенерированные этим компилятором,
будут работать наряду с другими
.NET-прило-жениями и будут иметь
такую же возможность
взаимодействия.
С CLR связана важная концепция управляемого
кода (managed code) — кода,
выполняемого только в среде CLR и
управляемого ею. Напомню, что во
время исполнения в нынешних ОС
Microsoft Windows мы имеем дело с
разнородными независимыми друг от
друга процессами. Единственное
требование, которому должны
отвечать приложения в среде
Windows, состоит в том, чтобы они
правильно работали. Эти приложения
создаются совершенно разными
компиляторами. Иначе говоря,
приложения должны подчиняться
только наиболее общим правилам
работы под Windows.
В среде Windows есть несколько
глобальных правил поведения
приложений, относящихся к их
взаимодействию друг с другом,
распределению памяти, а также к
привлечению средств самой ОС для
работы от их имени. Напротив, в
среде управляемого кода есть набор
правил, обеспечивающих
единообразное в глобальном смысле
поведение всех приложений
независимо от того, на каком языке
они написаны. Единообразное
поведение .NET-приложений —
характерная черта технологии .NET, и
его нельзя игнорировать. К счастью,
эти глобальные правила
распространяются главным образом
только на создателей компиляторов.
Библиотеки классов .NET Framework
Библиотеки классов .NET Framework
играют чрезвычайно важную роль в
обеспечении межъязыкового
взаимодействия приложений, так как
они позволяют разработчикам
использовать единый программный
интерфейс ко всем функциональным
средствам CLR. Если вам приходилось
писать программы для Windows на
нескольких языках, то вам
понравится это новшество.
Библиотеки классов .NET Framework делают
фактически революционный прорыв в
разработке компиляторов. До .NET
почти каждый автор компилятора
разрабатывал язык, обладающий
способностью делать большую часть
своей собственной работы. Даже C++,
разработанный как набор
функциональных возможностей,
работающих совместно с библиотекой
классов, имеет некоторые средства
для собственных нужд. Тогда как
роль языков в окружении .NET не
исчерпывается предоставлением
синтаксических интерфейсов к
библиотекам классов .NET Framework.
В качестве иллюстрации к
сказанному сравним версии
традиционного приложения "Hello,
World" на языках C++ и С#.
tfinclude <iostream.h>
int main(int argc, char* argv[]) {
cout " "Hello, World!" " endl;
return 0; }
В начало приложения включен
заголовочный файл с объявлением
функции cout. Функция main — входная
точка любого приложения на C/C++ —
выводит на стандартное устройство
вывода с помощью функции cout строку
"Hello, World". Здесь для нас важно
то, что написать такое приложение
на языке .NET без библиотек классов
.NET Framework нельзя. Это действительно
так: в .NET-языках нет присущих
обычным компиляторам основных
элементов, которые, например,
выводят на консоль строку текста.
Да, с точки зрения технологии,
реализация функции cout находится
в той части C/C++, которая сама
является библиотекой. И все-таки
основные задачи C++, такие как
форматирование строк, файловый
ввод-вывод и вывод на экран, хотя бы
формально считаются частью
исходного языка. Что касается С# (и
это характерно для любого .NET-языка),
то он не в состоянии выполнить даже
самую примитивную задачу без
привлечения библиотеки классов .NET
Framework. А так выглядит пример "Hello,
World" на языке С#:
using System;
class Hello {
public static void Main()
{
Console.WriteLine("Hello,
World");
} >
Итак, что дает этот стандартный
набор библиотек классов и чем он
хорош? Это зависит от точки зрения.
Благодаря такому набору все языки в
идеале располагают одними и теми же
функциональными возможностями,
поскольку все они могут что-то
делать (если речь идет не только об
объявлении переменных) только с
помощью этих библиотек.
Кто-то на дискуссионной страничке
в Интернете недоумевал: "Зачем
нам столько языков, если у них
одинаковые функциональные
возможности?" Как человек,
поработавший в нескольких
многоязыковых средах, заявляю, что
это очень здорово, когда не надо
помнить, какой язык, что и как может
делать с системой. В конце концов
мы, как разработчики, должны
написать код, не мучая себя
вопросом, есть ли у нашего любимого
языка то или иное преимущество.
Еще один частый вопрос: "Если
все .NET-языки могут делать одно и то
же, зачем нам много таких языков?"
Ответ надо искать в том, что
программисты — это люди, которые
редко отказываются от своих
привычек. Microsoft, конечно, стремится
выделить из множества языков
какой-то один и навязать его
миллионам программистов, имеющим
многолетний опыт работы с другими
языками. Мало того, что
разработчику нужно познакомиться с
новым API, ему придется еше освоить
совершенно другой синтаксис. Пусть
уж разработчик продолжает писать
на том языке, который лучше всего
подходит для его задачи. Как никак,
наша главная цель —
производительность. А замена того,
что не должно меняться, — не то, к
чему мы должны стремиться.
ПРИМЕЧАНИЕ В
идеале библиотеки классов .NET Framework
открывают пользователям языка все
функциональные возможности CLR,
однако на самом деле так бывает не
всегда. Камнем преткновения между
разработчиками библиотек классов
.NET Framework и разработчиками
компиляторов является то, что
первые хотя и попытались открыть
для любых языков все
функциональные возможности
библиотек классов, последних
все-таки ничто не обязывает делать
реализацию каждой такой
возможности (не пренебрегая,
правда, минимальными стандартами
CLS). Когда я спросил в Microsoft об этом
противоречии, мне ответили, что
вряд ли каждый язык будет иметь
доступ ко всем функциональным
возможностям .NET Framework, поскольку
каждая бригада разработчиков
компиляторов вправе реа^ лизовать
только те, что они считают самыми
нужными для своих пользователей. К
нашему счастью, С# — поидимому, тот
язык, в котором имеется интерфейс
практически ко всем функциональным
возможностям .NET Framework.
Microsoft Intermediate Language и компиляторы JITter
Для облегчения перевода языков в
среду .NET в Microsoft разработан промежуточный
язык — Microsoft Intermediate Language (MSIL).
Чтобы откомпилировать приложение
для .NET, компиляторы берут исходный
код и создают из него MSIL-код. MSIL —
это полноценный язык, пригодный для
написания приложений. Однако, как в
случае с ассемблерным языком, вам
вряд ли придется этим заниматься,
кроме каких-то особых
обстоятельств. Каждая группа
разработчиков компилятора решает,
в какой мере он будет поддерживать
MSIL. Но если создатели компиляторов
захотят, чтобы их язык полноценно
взаимодействовал с другими
языками, им придется ограничить
себя рамками, определяемыми
спецификациями CLS.
Результатом компиляции
приложения, написанного на С# или
другом языке, который отвечает
правилам CLS, является MSIL-код. Потом,
при первом запуске приложения в
среде CLR, MSIL-код компилируется в
машинные команды, специфичные для
данного процессора. (На самом деле
компилируются только функции,
вызываемые впервые.)
Поскольку мы все пока новички в этой технологии, а книга наша посвящена С#, посмотрим по порядку, что же происходит с кодом.
Унифицированная система типов
Одна из ключевых черт любой среды
разработки — ее система типов. Если
среда разработки имеет небольшой
выбор типов или ограничивает
возможность программиста
добавлять свои типы, то такая среда
проживет недолго. CLR не только
предоставляет разработчику единую
унифицированную систему типов,
доступную для всех CLS-совместимых
языков, но и позволяет создателям
языков расширять систему типов
путем добавления новых типов, по
виду и поведению ничем не
отличающихся от встроенных типов.
Это означает, что разработчик может
работать со всеми типами
единообразно независимо от того,
стандартные это типы или вновь
созданные. Подробнее о системе
типов и ее поддержке компилятором
С# см. главу 4.
Метаданные и отражение
Как уже говорилось в разделе
"Microsoft Intermediate Language и компиляторы
JITter", CLS-совместимые компиляторы
создают из вашего исходного кода
MSIL-код, подлежащий компиляции (с
помощью ЛТ-ком-пиляторов) перед
своим выполнением. Помимо перевода
исходного кода в
MSIL-последовательность,
CLS-совместимые компиляторы
выполняют и другую столь же важную
задачу: внедрение метаданных в
выходной ЕХЕ-файл.
Метаданные (metadata) — это данные
описывающие другие данные. В нашем
контексте — это набор программных
элементов ЕХЕ-файла, таких как типы
и реализации методов. Не правда ли,
звучит знакомо? Эти метаданные
похожи на библиотеки типов (typelib),
генерируемые компонентами Component
Object Model (COM). Метаданные, порождаемые
.NET-компилятором, как правило, не
только намного выразительнее и
полнее, чем библиотеки типов СОМ, к
которым мы успели привыкнуть.
Метаданные также всегда внедрены в
ЕХЕ-файл. Благодаря этому исключены
случайные потери метаданных
приложения и рассогласование
файлов.
Причина использования метаданных
очевидна. Благодаря этой
технологии CLR узнает, какие во время
выполнения потребуются типы и
какие методы должны быть вызваны.
Это дает среде возможность
выполнить должную настройку для
более эффективного выполнения
приложения. Механизм запроса
метаданных называется отражением
(reflection). Библиотеки классов .NET
Framework имеют целый набор методов
отражения, позволяющих любому
приложению (и не только CLR)
запросить метаданные другого
приложения.
Такие инструменты, как Visual Studio.NET,
используют методы отражения для
реализации средств подобных
IntelliSense. При наличии Inte-lliSense вы,
набирая имя метода, видите на
экране всплывающий список с
аргументами этого метода. Visual Studio.NET
дополняет это средство, показывая
еще и все члены типа. Об API отражения
см. главу 15.
Еще один чрезвычайно полезный .NET-инструмент, использующий преимущество отражения, — Microsoft .NET Framework IL Disassembler (ILDASM). Эта мощная утилита выполняет синтаксический разбор метаданных выбранного приложения, а затем отображает информацию о нем в виде дерева. Вот как выглядит приложение "Hello, World" на С# в ILDASM (рис. 2-1):
Рис 2.1. Приложение С# "Hello, World!", отображенное в ILDASM.
На втором плане — главное окно IL
Disassembler. Если дважды щелкнуть метод Main
в иерархическом дереве, на
переднем плане появится окно,
отображающее подробности метода Main.
Безопасность
Самый важный аспект любой среды
разработки распределенных
приложений — способ обеспечения
безопасности. Благодаря тем из нас,
кто долго жаловался, что никто не
будет всерьез рассматривать Microsoft в
отношении серверных решений для
предприятий, пока она полностью не
обновит подход к безопасности, в .NET
появилось сразу несколько новых
концепций. Работа системы
безопасности начинается с того
момента, когда CLR загружает класс,
поскольку загрузчик классов
является частью системы
безопасности .NET. Так, при загрузке
класса в .NET во время выполнения
проверяются правила доступа и его
внутренняя целостность. Кроме того,
в ходе такой проверки выясняется,
какая часть кода имеет надлежащие
разрешения на доступ к
определенным ресурсам. Система
безопасности гарантирует проверку
предписанных ролей и
идентификационных данных. Чтобы не
подвергать риску наиболее
ответственные данные в
распределенных вычислительных
средах, эти проверки безопасности
не ограничиваются рамками
отдельных процессов и машин.
Развертывание
Развертывание — наиболее
неприятная процедура разработки
крупных распределенных систем.
Любой разработчик Windows-программ
может сказать, что, столкнувшись с
массой разнообразных двоичных
файлов, проблемами реестра Windows,
компонентами СОМ, установкой
библиотек поддержки таких
продуктов, как Open Database Connectivity (ODBC) и
Data Access Objects (DAO), вы крепко
задумаетесь, а правильно ли вы
выбрали род занятий. Слава Богу,
развертывание — это та часть .NET,
над которой проектировщики хорошо
потрудились.
Ключ к развертыванию
.NET-приложений — концепция сборок (assemblies).
Сборкой называют пакет из
семантически близких объектов,
состоящий из одного или нескольких
файлов. Особенности развертывания
зависят от того, что вы
разрабатываете: Web-серверное
приложение или персональное
приложение для Windows. Однако с
введением сборки как полностью
инкапсулированного набора
функциональных возможностей
развертывание сводится к простому
копированию нужных сборок в место
назначения.
Масса проблем, мучивших
программистов до появления .NET
Framework, теперь устранено. Теперь,
например, не надо регистрировать
компоненты (как это требуют СОМ и
элементы управления ActiveX),
поскольку благодаря метаданным и
отражению все компоненты содержат
в себе собственное описание. Во
время выполнения .NET отслеживает
также работу с файлами и версии
файлов, связанных с приложением.
Поэтому любое устанавливаемое
приложение, автоматически
связывается с файлами, являющимися
частью его сборки. Если программа
установки попытается перезаписать
файл, необходимый другому
приложению, .NET поступит достаточно
умно, разрешив установить нужные
файлы, не удалив при этом
предыдущие версии файла, поскольку
они еще нужны другому приложению.
Взаимодействие с неуправляемым кодом
Как вы, наверное, догадались, неуправляемым (unmanaged code) называется код, который не находится под надзором .NET. Поясним: этот код тоже запускается средствами .NET. Однако у неуправляемого кода нет тех преимуществ, которыми обладает управляемый: сбора мусора, унифицированной системы типов и метаданных. Вы спрашиваете, зачем запускать неуправляемый код в среде .NET? Правильно, без особой нужды этого делать не стоит. Однако вы пойдете на это, когда у вас не будет другого выхода. Вот несколько ситуаций, которые показывают, что можно поблагодарить Microsoft за то, что в .NET заложена эта особенность.
Подведем итоги
Microsoft .NET — это переход на вычислительную модель, в которой устройства, службы и компьютеры работают совместно, обеспечивая создание решений для пользователей. Центром этого перехода являются разработка .NET Framework и CLR (рис. 2-2). .NET Framework содержит библиотеки классов, совместно используемые различными языками, которые компилируются для запуска в среде CLR. Поскольку С# разработан для CLR, вы не сможете решить даже простейшие задачи без CLR и библиотек классов .NET Framework. Понимание особенностей этих технологий является необходимым условием для получения максимальной пользы от С#, а как этого добиться, вы узнаете из основной части этой книги.
http://www.realcoding.net/article/view/2873