Предыдущая страница реферата | 1  2  3  4 | Следующая страница реферата

Затем вы компилируете его с помощью компилятора языка С# в ЕХЕ-файл.

Компилятор создает MSIL-код и помещает в раздел "только-на-чте-ние" выходного файла стандартный РЕ-заголовок (признак машино-независимой выполняемой программы для Win32). Пока все хорошо. Но здесь появляется очень важная деталь: при создании выходного файла компилятор импортирует из CLR функцию _CorExeMain.

Когда приложение начинает выполняться, ОС загружает этот РЕ (впрочем, как и обычный РЕ), а также все нужные DLL, в частности, библиотеку, которая экспортирует функцию _CorExeMain (mscoree.dll).

Загрузчик ОС выполняет переход в точку входа РЕ, устанавливаемую компилятором. Это ничем не отличается от процедуры загрузки в Windows любого другого РЕ.

Однако так как ОС не в состоянии выполнить MSIL-код, то фактически в точке входа содержится заглушка, в которой установлена команда перехода к функции jCorExeMain из mscoree.dll.

Функция JCorExeMain переходит к выполнению MSIL-кода, помещенного в РЕ.

Так как MSIL-код не может быть выполнен непосредственно (ведь это не машинный код), CLR компилирует его с помощью оперативного (just-in-time, или JIТ) компилятора (его еще называют JITter) в команды процессора. Эта компиляция выполняется только для непосредственно вызываемых методов программы. Откомпилированный выполняемый код сохраняется на машине и перекомпилируется только в случае изменения исходного кода. Для преобразования MSIL в настоящий машинный код можно применить один из следующих JIТ-компиляторов.

Генератор кода при установке (Install-time code generation) Выполняет компиляцию всей сборки в двоичный код, специфичный для данного процессора, подобно тому, как это делает компилятор С#. Сборка (assembly) — это комплект модулей кода, посылаемый компилятору. (О сборках подробнее я расскажу ниже в разделе "Развертывание".) Эта компиляция выполняется в ходе установки, когда обработка Сборки ЛТ-компилятором меньше всего заметна для конечного пользователя. Достоинство этого типа генерации двоичного кода в том, что компиляция всей сборки выполняется один раз еще до запуска приложения. Поскольку код скомпилирован, то о потере производительности при первом вызове метода приложения можно не беспокоиться. Это аналогично тому, как квартиросъемщик, чтобы каждый месяц не болела голова, где взять деньги на очередную выплату, платит вперед сразу за весь период. Вопрос о целесообразности применения этой утилиты решается в зависимости от размера конкретной системы и среды, в которой происходит ее развертывание. Если вы, как это часто бывает, собираетесь создать для своей системы установочное приложение, используйте этот ЛТ-компилятор, чтобы у пользователя была уже полностью оптимизированная версия системы "с иголочки".

JIT Стандартный JITter, вызываемый при выполнении приложения каждый раз для впервые активизируемого метода (в порядке, описанном выше). Это напоминает плату в намеченный срок. Данный режим работает по умолчанию, если вы не запускаете явно компилятор РrеJIТ.

EconoJIT Включается во время выполнения приложения и предназначен специально для систем, которые имеют ограниченные ресурсы, например, для портативных устройств с малым размером памяти. Основное отличие этого компилятора от обычного JITter — в объединении кодовых фрагментов (code pitching). Благодаря разбивке кода на фрагменты EconoJIT может удалить сгенерированный (т. е. откомпилированный) код, если памяти для запуска системы недостаточно. Достоинство этого компилятора в экономии памяти, а недостаток в том, что если фрагментированный код загружается вновь, он должен быть опять перекомпилирован как код, который еще никогда не вызывался.

  Унифицированная система типов

Одна из ключевых черт любой среды разработки — ее система типов. Если среда разработки имеет небольшой выбор типов или ограничивает возможность программиста добавлять свои типы, то такая среда проживет недолго. 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 заложена эта особенность.

Управляемый код, вызывающий функции неуправляемых DLL Допустим, вашему приложению нужно работать с DLL, написанной на С, а компания, создавшая эту библиотеку, пока не адаптировала ее для технологии .NET. В этом случае вам придется по-прежнему вызывать эту DLL из .NET-приложения. Такой пример описан в главе 16.

Рекомендуем скачать другие рефераты по теме: доклад на тему, механизм реферат.



Предыдущая страница реферата | 1  2  3  4 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки