Код, верифицированный на предмет того, что он не может обращаться к памяти вне домена приложения (кроме как  явным использованием удаленных  механизмов), называют безопасным, к типам в памяти (memory type-safe). Такой код может быть безопасно запущен параллельно с другим безопасным к типам кодом в разных доменах приложений в рамках одного процесса.

       3.4 Обработка ошибок с помощью исключений

       Среда .NET спроектирована для облегчения обработки ошибочных ситуаций на основе механизма, использующего исключения, который применяется также в языках Java и C++. Разработчики C++ должны отметить, что поскольку IL— строго типизированная система, в ней не происходит никакого снижения производительности, связанного с применением исключений, как это имеет место в C++. К тому же блок finally, о необходимости которого часто пишут разработчики C++, в .NET поддерживается изначально.

       Исключения  подробно рассматриваются в главе 14. Кратко говоря, идея заключается в том, что некоторые области кода могут быть помечены как процедуры обработки исключений, каждая из которых может обработать определенную ошибочную ситуацию (например, отсутствие файла либо отказ в доступе к какому-то действию). Эти условия могут быть определены насколько нужно узко либо насколько нужно широко. Архитектура исключений гарантирует, что при возникновении ошибочных условий выполнение немедленно перейдет к нужной процедуре-обработчику, которая в наибольшей степени подходит для обработки данного условия исключения.

       Архитектура обработки исключений также предоставляет  согласованную возможность передачи объектов процедуре-обработчику. Этот объект может включать соответствующее сообщение пользователю и подробности относительно того, где именно в коде было обнаружено исключение.

       Большая часть архитектуры обработки  исключений, включая поток управления программы при возникновении  исключительных ситуаций, обрабатывается языками высокого уровня (С#, Visual Basic 2008, C++) и не поддерживается никакими специальными командами IL. Так, например, С# обрабатывает исключения, используя блоки кода try{ }, catch{} и finally!}.

       Что делает .NET, так это предоставляет инфраструктуру, позволяющую компиляторам, ориентированным на .NET, поддерживать обработку ошибок. В частности, она предлагает набор классов, представляющих исключения, а также обеспечивает языковое взаимодействие, позволяющее обрабатывать объекты сгенерированных исключений в обработчиках, написанных на языках, не зависящих от языка, на котором реализован код, сгенерировавший исключение. Подобная независимость от языка недостижима ни в реализации исключений C++, ни в реализации Java, хотя и присутствует в ограниченном расширении механизма СОМ, обрабатывающего ошибки, который включает возврат кодов ошибок из методов и передачу объектов ошибки наружу. Факт согласованной обработки исключений в разных языках — ключевой аспект гибкости многоязычной разработки.

       3.5 Применение атрибутов

       Атрибуты — это средство, знакомое разработчикам C++, занятым созданием СОМ-компонентов (благодаря использованию языка определения интерфейса СОМ — Microsoft's COM Interface Definition Language, или, кратко, IDL). Первоначальная идея атрибута заключалась в том, чтобы предоставить дополнительную информацию относительно определенного элемента программы, который может быть использован компилятором.

       Атрибуты  поддерживаются в .NET и потому теперь поддерживаются в C++, С#, Visual Basic 2008. Что, однако, является новым в применении атрибутов .NET, так это то обстоятельство, что теперь есть возможность определять свои собственные настраиваемые атрибуты в исходном коде. Эти определенные пользователями атрибуты помещаются в метаданные, сопровождающие типы данных и методы программы. Это может оказаться удобным для целей документирования, когда атрибуты могут применяться совместно с технологией рефлексии для решения программистских задач, основанных на атрибутах. К тому же, в соответствии с философией языкового взаимодействия .NET, атрибуты могут быть определены в коде, написанном на одном языке, и прочитаны в коде, написанном на другом языке.

       4 СБОРКИ

       Сборка  (assembly) — это логическая единица, содержащая скомпилированный код для .NET Framework.

       Сборка— это полностью самодостаточный и, скорее, логический, нежели физический элемент. Это значит, что он может быть сохранен в более чем одном файле (хотя динамические сборки хранятся в памяти, а вовсе не в файлах). Если сборка хранится в более чем одном файле, то должен быть один главный файл, содержащий точку входа и описывающий остальные файлы.

       Следует отметить, что одна и та же структура  сборки используется как для исполняемого кода, так и для кода библиотек. Единственное реальное отличие исполняемой сборки заключается в том, что она содержит главную точку входа программы, тогда как библиотечная сборка — нет.

       Важное  свойство сборок состоит в том, что  они содержат метаданные, описывающие типы и методы, определенные в ее коде. Помимо этого сборка хранит в себе метаданные, описывающие ее саму. Эти метаданные, хранимые в области манифеста, позволяют выполнять проверку номера версии сборки и ее целостность.

       Для инспектирования содержимого сборки, включая манифест и метаданные, может  использоваться Windows-утилита ildasm.

       Тот факт, что сборка содержит метаданные программы, означает, что приложение или другие сборки, которые вызывают код данной, не нуждаются в обращении к реестру или любому другому источнику данных, чтобы узнать, как конкретную сборку следует использовать. Это существенный прорыв по сравнению со старым способом работы СОМ, когда GUID-идентификаторы компонентов и интерфейсов необходимо было извлекать из реестра, а подробности методов и свойств в некоторых случаях читать из библиотеки типов.

       Хранение  данных в трех различных местах приводило  к очевидному риску получить несинхронизированные части, что исключало возможность использования данного компонента другим программным обеспечением. Что касается сборок, то здесь риск подобного рода исключен, потому что все метаданные хранятся вместе с выполняемыми инструкциями программы. Следует отметить, что несмотря на то, что сборки могут храниться в нескольких файлах, не возникает проблемы синхронизации, поскольку в том же файле, где находится точка входа, хранится и информация о содержимом остальных файлов. То есть даже если один из них подменить или испортить, то это немедленно будет обнаружено, и всей сборке будет запрещено загружаться на выполнение. Сборки бывают двух видов: разделяемые и приватные.

       4.1 Приватные сборки

       Это простейший тип сборок. Обычно они  поставляются с определенным программным обеспечением и предназначены для использования только в его составе. Обычный сценарий получения приватной сборки — это когда вам поставляется приложение в виде исполняемой программы и множества библиотек, код которых может быть использован только этим приложением.

       Система гарантирует, что приватные сборки не будут использоваться другим программным обеспечением, потому что приложение может загружать только приватные сборки, находящиеся в той же папке, в которой хранится и главная исполняемая программа, которая их загружает, либо во вложенных папках.

       Поскольку обычно можно рассчитывать на то, что  коммерческое программное обеспечение  всегда инсталлируется в свой собственный  каталог, значит, нет опасности того, что один программный пакет перепишет, модифицирует или непреднамеренно загрузит приватные сборки, принадлежащие другому пакету. Поскольку приватные сборки могут быть использованы только тем пакетом программного обеспечения, для которого они предназначены, вы имеете возможность управлять тем программным обеспечением, которое их использует. Отсюда уменьшается необходимость в некоторых предосторожностях для обеспечения безопасности, поскольку нет риска, например, того, что какое-то коммерческое программное обеспечение перепишет ваши сборки их новыми версиями (за исключением тех случаев, когда программное обеспечение специально разработано для нанесения определенного вреда). Не существует также проблемы коллизии имен. Если окажется, что классы в вашей приватной сборке имеют те же имена, что и классы в чьей-то чужой приватной сборке, то это не имеет значения, поскольку каждое приложение будет в состоянии видеть только один набор собственных приватных сборок.

       Поскольку приватная сборка полностью самодостаточна, процесс ее развертывания весьма прост. Вы просто помещаете соответствующий файл (или файлы) в соответствующую папку системы (никаких записей вносить в реестр не потребуется). Этот процесс известен как инсталляция с нулевым воздействием (zero impact (xcopy) installation).

       4.2 Разделяемые сборки

       Назначение  разделяемых сборок — быть библиотеками общего применения, которые могут использоваться любым другим приложением. Поскольку любое другое приложение может получить доступ к разделяемой сборке, возникает необходимость в некоторых предосторожностях, дабы исключить следующие риски.

• Коллизия имен, когда разделяемая сборка, поставленная другой компанией, реализует типы с теми же именами, что используются в вашей сборке. Поскольку клиентский код теоретически может иметь доступ к двум таким сборкам одновременно, это может представлять серьезную проблему.
• Риск того, что данная сборка будет перезаписана другой версией той же сборки, и новая версия окажется несовместимой с некоторым существующим клиентским кодом.

       Решение этих проблем включает размещение разделенных  сборок в специальном поддереве  каталогов файловой системы, известном  под названием глобальный кэш сборок (global assembly cache— GAC). В отличие от приватных сборок, эти не могут быть просто скопированы в определенную папку— их надо специальным образом инсталлировать в упомянутом кэше. Процесс может быть реализован множеством утилит .NET и включает в себя выполнение необходимых проверок устанавливаемой сборки, а также создания небольшой иерархии папок в пределах GAC, используемых для обеспечения целостности сборок.

       Чтобы исключить коллизии имен, разделяемым  сборкам присваиваются имена, основанные на шифровании индивидуальным ключом (в отличие от приватных сборок, которым дается имя, совпадающее с именем главного файла). Это имя, известное как строгое имя, гарантировано уникальное, и оно должно быть указано приложением, ссылающимся на данную разделенную сборку.

       Проблемы, связанные с риском перезаписи сборки, решаются указанием информации о версии в манифесте сборки, а также возможностью параллельных инсталляций различных версий данной сборки.

       4.3 Рефлексия

       Поскольку сборки хранят в себе метаданные, включая  подробности устройства типов и членов этих типов, определенных в сборке, существует возможность получения программного доступа к этим метаданным. Эта технология, известная как рефлексия (reflection), открывает интересные возможности, поскольку означает, что управляемый код может исследовать другой управляемый код, или даже исследовать самого себя, чтобы извлечь информацию о коде. Чаще всего это используется для получения подробностей об атрибутах, хотя также, помимо прочего, вы можете применять рефлексию в качестве непрямого способа создания экземпляров классов или вызова методов, располагая их имена в виде строк. Таким образом, на основе пользовательского ввода вы можете во время выполнения, а не во время компиляции выбирать классы для создания их экземпляров и методы для вызова (то, что называется динамическим связыванием).

       5 КЛАССЫ .NET FRAMEWORK

       Возможно, наибольшее преимущество написания  управляемого кода — по крайней  мере, с точки зрения разработчика — состоит в том, что вы получаете возможность использовать библиотеку базовых классов .NET.

       Базовые классы .NET представляют огромную коллекцию классов управляемого кода, позволяющие решать практически любые задачи, которые раньше можно было решать с помощью Windows API. Все эти классы следуют той же объектной модели IL с одиночным наследованием. Это значит, что вы можете либо создавать объекты любого из базовых классов .NET, либо наследовать от них собственные классы.

       Отличие базовых классов .NET заключается в том, что они спроектированы так, что интуитивно понятны и просты в использовании. Например, чтобы запустить поток, нужно вызвать метод Start() класса Thread. Чтобы сделать недоступным объект TextBox, нужно присваивоить свойству Enabled этого объекта значение false. Такой подход, хорошо знакомый разработчикам Visual Basic и Java, чьи библиотеки использовать так же легко, принесет огромное облегчение разработчикам C++, которым в течение многих лет приходилось "воевать" с такими API-функциями, как GetDIBits (), RegisterWndClassEx () и IsEqualllD (), а также с множеством функций, которые требовали передачи дескрипторов окон.

       Однако  разработчики на C++ всегда имели легкий доступ к полному набору Windows API, в то время как разработчики на Visual Basic 6 и Java были ограничены в использовании базовой функциональности операционной системы, доступ к которой они получали из своих языков. Что касается базовых классов .NET, то они комбинируют простоту использования, присущую библиотекам Visual Basic и Java, с относительно полным покрытием набора функций Windows API. Многие средства Windows не доступны через базовые классы, и в этих случаях вам придется обращаться к API-функциям, но, в общем, это касается лишь наиболее экзотических функций. Для каждодневного применения набора базовых классов, в основном, будет достаточно. Но если вам понадобится вызвать API-функцию, то для этого .NET предоставляет так называемый механизм вызова платформы, гарантирующий правильное преобразование типов данных, поэтому теперь эта задача не труднее, чем вызов этих функций непосредственно из кода C++, причем независимо от того, на каком языке нужно кодировать: на С#, C++ или Visual Basic 2008.

       Для просмотра классов, структур, интерфейсов  и перечислений базовой библиотеки классов может использоваться Windows-утилита WinCV.

       Ниже  приведен не список наиболее значимых областей, которые обслуживают базовые классы .NET В.5.