Программный доступ к пространствам имен
Не помешает повторить снова, что пространство имен является ничем иным, как подходящим для человека способом логически понять и организовать связанные типы. Снова рассмотрим пространство имен System. Можно считать, что System.Console представляет класс, названный Console и содержащийся в пространстве имен System. Но для среды выполнения .NET это не так. Механизм среды выполнения видит только отдельную единицу, названную System.Console.
В C# ключевое слово using упрощает ссылки на типы, определенные в данном пространстве имен. Вот как оно используется. Допустим, вы строите традиционное приложение для настольной системы. В главном окне должна отображаться некоторая диаграмма, основанная на информации, полученной от внутренней базы данных, и логотип компании. Конечно, для изучения типов в пространствах имен требуется время, но вот несколько очевидных "кандидатов", подходящих для ссылок в описанной выше программе.
// Пространства имен, необходимые для данного приложения.
using System; // Общие типы базовых классов,
using System.Drawing; // визуализация графики,
using System.Windows.Forms; // GDI-элементы,
using System.Data; // общий доступ к данным,
using System.Data.SqlClient; // доступ к данным MS SQL Server.
Выбрав некоторое число пространств имен (и указав ссылки на компоновочные блоки, которые их определяют), вы получаете возможность создавать экземпляры соответствующих типов. Например, если вы хотите создать экземпляр класса Bitmap (из пространства имен System.Drawing), вы можете использовать следующий программный коя,
// Явный список пространств имен, используемых в данном файле.
using System;
using System.Drawing;
class MyApp {
public void DisplayLogo() {
// Создание изображения 20x20.
Bitmap companyLogo = new Bitmap(20, 20);
...
}
}
Поскольку ваше приложение ссылается на System.Drawing, компилятор сможет выяснить, что класс Bitmap является членом указанного пространства имен. Если бы вы не указали здесь пространство имен System.Drawing, то получили бы ошибку компиляций. Но для определения переменных можно также использовать полностью определённое, или абсолютное имя.
// Здесь System.Drawing не указывается!
Using System;
class MyApp {
public void DisplayLogo() {
// Использование абсолютного имени
System.Drawing.Bitmap companyLogo = new System.Drawing.Bitmap(20, 20);
…
}
}
Использование абсолютных имен для определения типа, конечно, упрощает понимание программного кода, но я думаю, и вы не станете возражать, что ключевое слово C# using уменьшает объем необходимого ввода. В этом тексте мы будем избегать использования абсолютных имен (за исключением тех случаев, когда из-за этого возникает явная неоднозначность), отдавая предпочтение использованию ключевого слова using.
При этом следует понимать, что использование using является лишь альтернативой использования абсолютных имен, поскольку в программном коде CIL всегда используются абсолютные имена, так что оба указанных подхода дают совершенно одинаковые результаты в CIL и с точки зрения производительности, и с точки зрения размера компоновочного блока.
Ссылки на внешние компоновочные блоки
Вдобавок к указанию пространства имен с помощью ключевого слова C# using, необходимо указать компилятору C# имя компоновочного блока, содержащего реальное CIL-определение соответствующего типа. Выше уже упоминалось, что многие базовые пространства имен .NET содержатся в mscorlib.dll. Однако тип System.Drawing.Bitmap содержится в другом компоновочном блоке с именем System.Drawing.dll. Большинство компоновочных блоков .NET Framework размещается в специальном каталоге, называемом GAC (Global Assembly Cache - глобальный кэш компоновочных блоков). На машинах Windows это может быть каталог %windir%Assembly, как показано на рис. 1.5.
Рис. 1.5. Библиотеки базовых классов в GAC
В зависимости от используемого инструмента разработки приложений .NET может быть несколько разных способов информирования компилятора о том, какие компоновочные блоки следует включить в цикл компиляции. Подробно это будет обсуждаться в следующей главе.
Если вас пугает перспектива освоения всех пространств имен платформы .NET, вспомните о том, что уникальность любого пространства имен заключается в том, что оно содержит типы, некоторым образом семантически связанные между собой. Поэтому, например, если вам не нужен интерфейс пользователя для простого консольного приложения, то смело можете забыть (среди прочих) о пространствах имен System.Windows.Forms и System.Web. Если вы строите приложение для работы с изображениями, то вам вряд ли понадобятся пространства имен для работы с базами данных. К тому же, как в случае любой новой библиотеки готового программного кода, вы можете учиться по ходу дела.
Утилита ildasm.exe (Intermediate Language Disassembler utility – утилита дизассемблера промежуточного языка) позволяет загрузить любой компоновочный блок .NET и исследовать его содержимое, включая соответствующий манифест, программный код CIL и метаданные типов.
По умолчанию файл ildasm.exe должен быть установлен в папку C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bin (если вы не можете найти ildasm.exe в указанном месте, просто выполните поиск файла по ключу "ildasm.exe" на своей машине).
Обнаружив и запустив этот файл, а открывшемся окне выберите команду меню File→Open и перейдите к компоновочному блоку, который вы хотите исследовать. С целью иллюстрации здесь (рис. 1.6) показав компоновочный блок CSharpCalculator.exe, о котором уже шла речь выше. Утилита ildasm.exe представляет структуру компоновочного блока, используя всем знакомый формат дерева просмотра.
Рис. 1.6. Ваш новый лучший друг ildasm.exe
В дополнение к тому, что вы можете видеть пространства имен, типы и их члены в компоновочном блоке. Ildasm.exe дозволяет также просмотреть CIL-инструкции любого члена. Например, если выбрать двойным щелчком метод Main() класса CalcApp, то появится отдельное окно, в котором будет отображаться соответствующий CIL-код (рис. 1.7).
Рис. 1.7. Просмотр CIL-кода
Просмотр метаданных типов
Если вы захотите просмотреть метаданные типов для загруженного в настоящий момент компоновочного блока, просто нажмите ‹Ctrl+M›. На рис. 1.8 показаны метаданные для метода Calc.Add().
Рис. 1.8. Просмотр метаданных типов с помощью ildasm.exe
Просмотр метаданных компоновочных блоков
Наконец, если вы захотите просмотреть содержимое манифеста компоновочного блока, то вам нужно двойным щелчком открыть пиктограмму MANIFEST (рис. 1.9).
Рис. 1.9. Двойной щелчок на этой строке покажет манифест компоновочного блока
Не сомневайтесь в том, что ildasm.exe имеет не только те опции, о которых говорилось выше. Дополнительные возможности этого инструмента будут обсуждаться и дальше. По мере чтения материала книги я рекомендую вам просматривать ваши компоновочные блоки с помощью ildasm.exe, чтобы вы видели, как ваш программный код C# транслируется в независимый от платформы программный код CIL. Конечно, чтобы быть суперзвездой C#, совсем не обязательно быть экспертом по программному коду CIL, но понимание синтаксиса CIL только укрепит ваши "мускулы программирования".
Инсталляция среды выполнения .NET
Для вас не должно быть сюрпризом то, что компоновочные блоки .NET могут выполняться только на машине, на которой установлен каркас .NET Framework. Для вас, как для разработчика .NET-приложений, это не должно быть проблемой, поскольку ваша машина будет должным образом сконфигурирована уже в процессе установки свободно доступного пакета .NET Framework 2.0 SDK (или любой коммерческий среды разработки .NET-приложений, например Visual Studio 2005).
Однако, если вы развернете компоновочный блок на компьютере, который не имеет установленной системы .NET, этот компоновочный блок выполняться не сможет. По Этой причине Microsoft предлагает установочный пакет dotnetfx.exe, который может быть бесплатно получен и установлен вместе с вашим программным обеспечением. Эта установочная программа включена в .NET Framework 2.0 SDK, а также доступна для бесплатной загрузки с узла Microsoft.
После установки dotnetfx.exe ваша машина будет содержать библиотеки базовьх классов .NET, файлы среды выполнения .NET (mscoree.dll) и дополнительно инфраструктуру .NET (например, GAC).
Замечание. При построении Web-приложений .NET не предполагается, что на машине конечного пользователя будет установлен каркас .NET Framework, поскольку браузер конечного пользователи просто получает общий HTML-код и, возможно, JavaScript-код клиента.
