Платформа Microsoft. 
NET Framework

Министерство образования Республики Беларусь Учреждение образования

" Белорусский государственный университет информатики и радиоэлектроники"

Факультет компьютерного проектирования

Реферат

по предмету «Основы информационных технологий«

на тему: «Платформа Microsoft. NET Framework»

Минск 2011

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

Целью данной работы является дать краткое описание платформы Microsoft. NETF ramework, ее структуры и принципов работы, показать ее преимущества и недостатки перед другими существующими технологиями, а также последние нововведения в платформу и перспективы ее развития.

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

Единая модель программирования, API-интерфейс и язык программирования — большой шаг вперед в области технологий абстрагирования и огромная помощь разработчикам в их работе. Все функции NETF ramework направлены на то, чтобы оставить в прошлом проблемы интеграции, что значительно упростило тестирование, развертывание, администрирование, управление версиями, повторное использование и переориентацию кода на выполнение других задач.

1. Обзор существующих технологий разработки программного обеспечения

Обзор платформы Microsoft NETF rameworkследует начать с обзора уже существующих альтернативных технологий, призванных облегчить создание архитектуры и реализацию исходного кода приложений. Некоторые примеры таких технологий:

Microsoft Foundation Class (MFC) — уровень абстрагирования, служащий в языке C++ для программирования графического пользовательского интерфейса для операционных систем Windows. Используя MFC, разработчики могут больше внимания уделить самой программе и меньше заниматься циклами обработки сообщений, оконными процедурами, классами окон и т. п.

Java и J2EE— полностью объектно-ориентированный, межплатформенный язык программирования и платформа на его основе для создания приложений уровня предприятия. Программы на Java транслируются в байт-код, выполняемый виртуальной машиной Java (JVM) — программой, обрабатывающей байтовый код и передающей инструкции оборудованию как интерпретатор, но с тем отличием, что байтовый код, в отличие от текста, обрабатывается значительно быстрее[2].

ActiveServerPages (ASP)— служит для абстрагирования при создании активных и динамических Web-сайтов с использованием VisualBasicScript или JScript. Эта технология позволила разработчикам абстрагироваться от особенностей сетевых взаимодействий и больше внимания уделять содержанию Web-страниц.

ActiveTemplateLibrary (ATL) — уровень абстрагирования, облегчающий создание компонентов, которые доступны для использования специалистами, работающими с различными языками программирования.

Все эти технологии абстрагирования создавались, чтобы разработчики могли забыть о технических деталях и сосредоточиться на конкретных вещах, будь то приложения с графическим пользовательским интерфейсом, Web-приложения или компоненты. Несмотря на то, что эти технологии значительно облегчали работу, они требовали от программиста осваивать массу материала. Также различные технологии разрабатывались без расчета на совместное использование, и разработчики сталкивались с необходимостью решать непростые проблемы интеграции[1].

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

Все функции NETF ramework направлены на то, чтобы оставить в прошлом проблемы интеграции, что значительно упростило тестирование, развертывание, администрирование, управление версиями, повторное использование и переориентацию кода на выполнение других задач[3].

2. Описание платформы NET Framework

При проектировании платформы Net Framework, компания Microsoft учла недостатки существующихWindows-платформ.NET Framework состоит из двух частей: общеязыковой исполняющей среды (commonlanguageruntime, CLR) и библиотеки классов (Framework Class Library, FCL). CLR предоставляет модель программирования, используемую во всех типах приложений. У CLR собственный загрузчик файлов, диспетчер памяти (сборщик мусора), система безопасности (безопасность доступа к коду), пул потоков и многое другое. Кроме того, CLR предоставляет объектно-ориентированную модель программирования, определяющую, как выглядят и ведут себя типы и объекты. FCL предоставляет объектно-ориентированный API-интерфейс, используемый всеми моделями приложений. В ней содержатся определения типов, которые позволяют разработчикам выполнять ввод/вывод, планирование задач в других потоках, создавать графические образы, сравнивать строки и т. п. Естественно, что все эти определения типов соответствуют существующей модели программирования в CLR. Ниже представлен список возможностей и преимуществ платформы NET:

— Полное и абсолютное межъязыковое взаимодействие. В .NET Framework. Поддерживаются межъязыковое наследование, межъязыковая обработка исключений и межъязыковая отладка.

— Общая среда выполнения для любых приложений .NET, вне зависимости от того, на каких языках они были созданы. Один из важных моментов при этом то, что для всех языков используется один и тот же набор встроенных типов данных[2].

— Единая программная модель. В отличие от существующего подхода, когда одни функции операционной системы доступны через процедуры динамически подключаемых библиотек (DLL), а другие — через СОМ-объекты, весь прикладной сервис представлен общей объектно-ориентированной программной моделью.

— Упрощенная модель программирования. Избавляет от работы с разными структурами, как это было с Win32 и СОМ. Так, разработчику не нужно разбираться с реестром, глобальными уникальными идентификаторами (GUID), IUnknown, AddRef, Release, HRESULT и т. д.

— Отсутствие проблем с версиями. Все Windows-разработчики знают о проблемах совместимости версий, известных под названием «DLL hell». Эта проблема возникает, когда компоненты, устанавливаемые для нового приложения, заменяют компоненты старого приложения, и в итоге последнее начинает вести себя странно или перестает работать. Архитектура .NET Framework позволяет изолировать прикладные компоненты, так что приложение всегда загружает компоненты, с которыми оно строилось и тестировалось. Если приложение работает после начальной установки, оно будет работать всегда.

— Упрощенное развертывание. Ранее Windows-приложения было очень трудно устанавливать и разворачивать: обычно нужно было создать массу файлов, параметров реестра и ярлыков. К тому же полностью удалить приложение практически невозможно. С приходом NET Framework все эти проблемы остаются в прошлом. Компоненты NET Framework не связаны с реестром. Установка приложений NET Framework сводится лишь к копированию файлов в нужные каталоги и созданию ярлыков. Удаление же приложений сводится к удалению файлов.

— Работа на многих платформах. При компиляции кода для .NET Framework компилятор генерирует код на общем промежуточном языке (CommonItermediateLanguage, CIL), а не традиционный код, состоящий из процессорных команд. При исполнении CIL транслируется в команды процессора. Поскольку трансляция выполняется в период выполнения, генерируются команды конкретного процессора. Это значит, что можно развертывать свое приложение NET Framework на любой машине, где работает версия .NET Framework соответствующая стандарту ЕСМА: с архитектурой х86, х64, IA64 и т. д.

— Интеграция языков программирования. Технология СОМ поддерживает взаимодействие разных языков — .NET Framework обеспечивает интеграцию разных языков, то есть один язык может использовать типы, созданные на других языках. Например, .NET Framework позволяет создать на C++ класс, производный от класса, реализованного на VisualBasic. В CLR это возможно из-за наличия общей системы типов (Common Type System, CTS), которую должны использовать все языки, ориентированные на CLR. Общеязыковая спецификация (Common Language Specification, CLS) определяет правила, которым должны следовать разработчики компиляторов, чтобы их языки интегрировались с другими. Сама Microsoft предлагает несколько таких языков: C++/CLI (C++ с управляемыми расширениями), С#, VisualBasic NET. Кроме того, другие компании и учебные заведения создают компиляторы других языков, совместимых с CLR.

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

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

— Проверка безопасности типов CLR может проверять безопасность использования типов в коде, что гарантирует корректное обращение к существующим типам. Если входной параметр метода объявлен как 4-байтное значение, CLR обнаружит и предотвратит передачу 8-байтного значения в качестве значения этого параметра. Безопасность типов также означает, что управление может передаваться только в определенные точки (точки входа методов). Невозможно указать произвольный адрес и заставить программу исполняться, начиная с этого адреса. Совокупность всех этих защитных мер избавляет от многих распространенных программных ошибок (например, от возможности использования переполнения буфера для «взлома» программы).

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

— Единый принцип обработки сбоев. Один из самых неприятных моментов Windows-программирования — несогласованный стиль сообщений о сбоях. Одни функции возвращают коды состояний Win32, другие — HRESULT, третьи генерируют исключения. В CLR обо всех сбоях сообщается через исключения, которые позволяют отделить код, необходимый для восстановления после сбоя, от основного алгоритма. Такое разделение облегчает написание, чтение и сопровождение программ. Кроме того, исключения работают в многомодульных и многоязыковых приложениях. И в отличие от кодов состояний и HRESULT исключения нельзя проигнорировать. CLR также предоставляет встроенные средства анализа стека, заметно упрощающие поиск фрагментов, вызывающих сбои.

— Безопасность. Традиционные системы безопасности обеспечивают управление доступом на основе учетных записей пользователей. Это проверенная модель, но она подразумевает, что любому коду можно доверять в одинаковой степени. Такое допущение оправданно, когда весь код устанавливается с физических носителей (например, с компакт-диска) или с доверенных корпоративных серверов. Но по мере увеличения объема мобильного кода, например Web-сценариев, приложений, загружаемых из Интернета, и вложений, содержащихся в электронной почте, нужен ориентированный на код способ контроля за поведением приложений. Такой подход реализован в модели безопасности доступа к коду.

— Взаимодействие с существующим кодом. В Microsoft понимают, что разработчики накопили огромный объем кода и компонентов. Переписывание всего этого кода, так чтобы он задействовал все достоинства NET Framework, значительно замедлило бы переход к этой платформе. Поэтому в .NET Framework реализована полная поддержка доступа к СОМ-компонентам и Win32-функциям в существующих динамических библиотеках DLL[1].

3. Архитектура и принцип работы платформы NET Framework

3.1 Компиляция исходного кода

платформа net framework работа

При работе с платформой. NETможно создавать файлы с исходным кодом на любом языке, поддерживающем CLR. Затем соответствующий компилятор проверяет и анализирует исходный код. Независимо от компилятора результатом его работы является управляемый модуль (managedmodule) — стандартный переносимый исполняемый (portableexecutable, РЕ) файл 32-разрядной (РЕ32) или 64-разрядной Windows (PE32+), который требует для своего выполнения исполняемую среду CLR.

В прошлом почти все компиляторы генерировали код для конкретных процессорных архитектур, таких как x86, IA64, Alpha или PowerPC. Все CLR-совместимые компиляторы вместо этого генерируют IL-код. IL-код иногда называют управляемым (managedcode), потому что CLR управляет его жизненным циклом и выполнением.

Каждый компилятор, предназначенный для CLR, кроме генерации IL-кода, также должен создавать полные метаданные (metadata) для каждого управляемого модуля. Коротко говоря, метаданные — это просто набор таблиц данных, описывающих то, что определено в модуле, например типы и их члены. Метаданные служат многим целям:

— Они устраняют необходимость в заголовочных и библиотечных файлах прикомпиляции, так как все сведения о типах/членах, на которые есть ссылки, содержатся в файле с IL-кодом, в котором они реализованы. Компиляторы могут читать метаданные прямо из управляемых модулей.

— В процессе верификации кода CLR использует метаданные, чтобы убедиться, что код совершает только «безопасные» операции.

— Метаданные позволяют сериализовать поля объекта в блок памяти на удаленной машине и затем десериализовать, восстановив объект и его состояние на этой машине.

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

Метаданные расширяют возможности таких старых технологий, как библиотеки типов и файлы языка описания интерфейсов (Interface Definition Language, IDL). Важно заметить, что метаданные CLR гораздо полнее. И в отличие от библиотек типов и IDL они всегда связаны с файлом, содержащим IL-код. Фактически метаданные всегда встроены в тот же ЕХЕ/DLL, что и код, так что их нельзя разделить. Так как компилятор генерирует метаданные и код одновременно и привязывает их к конечному управляемому модулю, рассинхронизация метаданных и описываемого ими IL-кода исключена.

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

3.2 Процесс загрузки и исполнения кода в платформе NET

При выполнении исполняемого файла Windows анализирует заголовок ЕХЕ-файла на предмет необходимого для его работы адресного пространства — 32-или 64-разрядного. Файл с заголовком РЕ32 может выполняться в адресном пространстве любого из указанных двух типов, а файлу с заголовком РЕ32+ требуется 64-разрядное пространство. Windows также проверяет информацию о процессорной архитектуре на предмет совместимости с имеющейся конфигурацией.64-разрядные версии Windows поддерживают технологию выполнения 32-разрядных приложений в 64-разрядной среде, которую называют W0W64 (WindowsonWindows64). Она даже позволяет выполнять 32-разрядные приложения на машине с процессором Itanium за счет эмуляции команд х8б, но за это приходится расплачиваться снижением производительности.

После анализа заголовка ЕХЕ-файла для выяснения того, какой процесс запустить — 32-, 64-разрядный или WoW64, Windows загружает в адресное пространство процесса соответствующую (х86, х64 или IA64) версию библиотеки MSCorEE.dll. В Windows версии х86 одноименная версия MSCorEE. dll хранится в каталоге C: WindowsSystem32. В версиях х64 и IA64 версия х86 библиотеки находится в каталоге C: WindowsSysWow64, а 64-разрядная версия MSCorEE. dll (хб4 orIA64) размещается в каталоге C: WindowsSystem32 (это сделано из соображений обратной совместимости).

Далее основной поток процесса вызывает определенный в MSCorEE. dll метод, который инициализирует CLR, загружает сборку ЕХЕ, а затем ее метод точки входа (Main). На этом процедура запуска управляемого приложения считается завершенной.

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

Для выполнения какого-либо метода его IL-код должен быть преобразован в машинные команды. Этим занимается JIT-компилятор CLR. Рассмотрим пример:

publicvoidMain ()

{

Console.WriteLine («HelloWorld»);

}

Непосредственно перед исполнением метода Main среда CLR находит все типы, на которые ссылается код Main. При этом CLR выделяет внутренние структуры данных, используемые для управления доступом к типам, на которые есть ссылки. В примере метод Main ссылается на единственный тип — Console, и CLR выделяет единственную внутреннюю структуру. Эта внутренняя структура данных содержит по одной записи для каждого метода, определенного в типе Console. Каждая запись содержит адрес, по которому можно найти реализацию метода. При инициализации этой структуры CLR заносит в каждую запись адрес внутренней, недокументированной функции, содержащейся в самой CLR. Это функция JIT Compiler.

Функции JIT Compiler известен вызываемый метод и тип, в котором он определен. JIT Compiler ищет в метаданных соответствующей сборки IL-код вызываемого метода. Затем JIT Compiler проверяет и компилирует IL-код в собственные машинные команды, которые сохраняются в динамически выделенном блоке памяти.

После этого JIT Compiler возвращается к внутренней структуре данных типа и заменяет адрес вызываемого метода адресом блока памяти, содержащего готовые машинные команды. В завершение JIT Compiler передает управление коду в этом блоке памяти. Этот код — реализация метода Write Line (той его версии, что принимает параметр String). Из этого метода управление возвращается в Main, который продолжает выполнение в обычном порядке.

Затем Main обращается к Write Line вторично. К этому моменту код Write Line уже проверен и скомпилирован, так что обращение к блоку памяти производится, минуя вызов JIT Compiler. Отработав, метод Write Line возвращает управление Main. Снижение производительности наблюдается только при первом вызове метода. Все последующие обращения выполняются «на полной скорости»: повторная верификация и компиляция не производятся.

JIT-компилятор хранит машинные команды в динамической памяти. Это значит, что скомпилированный код уничтожается по завершении работы приложения. Так что, если потом снова вызвать приложение или если одновременно запустить второй его экземпляр (в другом процессе ОС), JIT-компилятор заново будет компилировать IL-код в машинные команды.

Для большинства приложений снижение производительности, связанное с работой JIT-компилятора, незначительно. Большинство приложений раз за разом обращается к одним и тем же методам. На производительности это скажется только раз. К тому же, скорее всего больше времени занимает выполнение самого метода, а не обращение к нему.

Полезно также знать, что JIT-компилятор CLR оптимизирует машинный код аналогично компилятору неуправляемого кода C++. Создание оптимизированного кода занимает больше времени, но производительность его будет гораздо выше, чем неоптимизированного.

Многие авторитетные авторы считают, что управляемые приложения могут работать производительнее неуправляемых, и тому есть масса причин. Взять хотя бы тот факт, что превращая IL-код в команды процессора в период выполнения, JIT-компилятор располагает более полными сведениями о среде выполнения, чем компилятор неуправляемого кода. Ниже перечислены особенности, которые позволяют управляемому коду работать производительнее неуправляемого:

— JIT-компилятор может обнаружить факт выполнения приложения на Pentium 4 и сгенерировать машинный код, полностью использующий все преимущества особых команд этого процессора. Неуправляемые приложения обычно компилируют в расчете на среднестатистический процессор, избегая специфических команд, которые заметно повышают производительность приложения на новейших процессорах.

— JIT-компилятор может обнаружить, что определенное выражение на конкретной машине всегда равно false. Например, посмотрим на метод с таким кодом:

if (numberOfCPUs> 1)

{

…

}

Здесь number OfCPUs — число процессоров. Код указывает JIT-компилятору, что для машины с одним процессором не нужно генерировать никаких машинных команд. В этом случае машинный код оптимизирован для конкретной машины: он короче и выполняется быстрее.

— CLR может проанализировать выполнение кода и перекомпилировать IL-код в команды процессора во время выполнения приложения. Перекомпилированный код может реорганизовываться с учетом обнаруженных некорректных прогнозов ветвления.

Это лишь малая часть аргументов в пользу того, что управляемый код будущего будет исполняться лучше сегодняшнего неуправляемого. Производительность и сейчас очень неплохая для большинства приложений, а со временем ситуация только улучшится[1].

3.3 IL-код и верификация

IL ориентирован на работу со стеком, то есть все его команды помещают операнды в стек исполнения и извлекают результаты из стека. Поскольку в IL нет команд работы с регистрами, это упрощает работу разработчикам компиляторов для CLR: не нужно думать об управлении регистрами, да и команд в IL меньше (за счет отсутствия тех же команд работы с регистрами).

Команды IL не связаны и с типами. Например, IL-команда add складывает два последних операнда, помещенных в стек; нет отдельных 32- и 64-разрядной версий команды. При выполнении add определяет типы операндов в стеке и делает, что требуется.

Главное достоинство IL не в том, что он позволяет абстрагироваться от конкретного типа процессора, а в надежности и безопасности приложений. При компиляции IL в машинный код CLR выполняет верификацию, в процессе которой проверяется, все ли «безопасно» делает высокоуровневый IL-код: например, нужное ли число параметров передается методу и корректны ли их типы, правильно ли используются возвращаемые методами значения, имеют ли все методы операторы возврата и т. д. Все необходимые для верификации сведения о методах и типах есть в метаданных управляемого модуля.

В Windows у каждого процесса собственное виртуальное адресное пространство. Отдельные адресные пространства нужны потому, что нельзя полностью доверять коду приложения. Весьма вероятно, что приложение будет считывать или записывать данные по недопустимому адресу. Размещение каждого процесса Windows в отдельное адресное пространство позволяет добиться надежности: процесс не может нарушить работу других.

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

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

CLR предоставляет возможность выполнения множества управляемых приложений в одном процессе ОС. Каждое управляемое приложение связано с доменом приложения (AppDomain). По умолчанию каждый управляемый ЕХЕ-модуль работает в собственном, отдельном адресном пространстве, где есть только один домен приложения. Однако процесс, являющийся хостом CLR (например, InternetInformationServices (IIS) или Microsoft SQL Server 2005), может выполнять домены приложений в одном процессе ОС[1].

3.4 Библиотека классов .NET Framework

В .NET Framework включены сборки библиотеки классов .NET FrameworkClassLibrary (FCL), содержащие определения нескольких тысяч типов, каждый из которых предоставляет некоторую функциональность. В Microsoft работают над дополнительными библиотеками WinFx и DirectX SDK, которые предоставляют еще больше типов и функциональности. Благодаря библиотеке классов разработчики могут создавать многие виды приложений, в том числе перечисленные далее:

— Web-сервисы — методы, которые позволяют легко обрабатывать сообщения на основе XML, пересылаемые через Интернет.

— WebForms — приложения, основанные на HTML (Web-сайты). Обычно приложения WebForms выполняют запросы к базам данных и вызовы Web-сервисов, объединяют и фильтруют полученные данные, а затем выводят их в браузере, предоставляя развитый пользовательский интерфейс, основанный на HTML.

— WindowsForms-Windows-приложения с богатым графическим пользовательским интерфейсом. Вместо создания пользовательского интерфейса на базе страниц WebForms можно задействовать мощь настольных приложений Windows. В приложениях WindowsForms можно использовать преимущества поддержки элементов управления, меню, событий мыши и клавиатуры и взаимодействия напрямую с ОС. Как и приложения WebForms, приложения WindowsForms выполняют запросы баз данных и вызовы Web-сервисов.

— Консольные приложения Windows — для задач, не требующих богатого пользовательского интерфейса, это оптимальное решение. Многие компиляторы, утилиты и инструменты обычно реализованы как консольные приложения.

— Службы Windows- .NET Framework позволяет строить приложения-службы, которыми управляет диспетчер Windows Service Control Manager (SCM).

— Библиотеки компонентов — NETFramework позволяет создавать автономные компоненты (типы), которые легко использовать со всеми перечисленными выше видами приложений.

Поскольку FCL насчитывает тысячи типов, наборы родственных типов скомпонованы в отдельные пространства имен. Так, пространство имен System содержит базовый класс Object, который, в конечном счете, порождает все остальные типы. Кроме того, пространство имен System содержит типы для целых чисел, символов, строк, обработки исключений, консольного ввода/вывода, а также группу полезных типов для безопасного преобразования типов, форматирования данных, генерирования случайных чисел и выполнения различных математических операций. Типами из пространства имен System пользуются все приложения.

Чтобы задействовать ту или иную функцию платформы, нужно знать пространство имен, содержащее тип, реализующий нужную функциональность. Чтобы изменить поведение FCL-типа, обычно просто создают производный тип.

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

Большинство пространств имен FCL предоставляет типы, которые можно задействовать в любых видах приложений.

4. Новые возможности платформы .NETFramework 4.0

В 2010 году компанией Microsoft была выпущена платформа NET Framework 4.0. Эта платформа содержит ряд усовершенствований и нововведений. Список некоторых из них представлен ниже:

— Среда DLR. Среда DLR представляет собой новую среду выполнения, которая расширяет среду CLR дополнительным набором служб для динамических языков. Среда DLR упрощает разработку динамических языков, используемых в NETF ramework и добавляет динамические функции в языки со статической типизацией. Для поддержки среды DLR в платформу NETF ramework добавлено новое пространство имен System.Dynamic.

— Сборка мусора. Платформа NETF ramework 4 обеспечивает фоновый сбор мусора. Эта функция заменяет параллельный сбор мусора в предыдущих версиях и обеспечивает повышенную производительность.

— Managed Extensibility Framework. Платформа Managed Extensibility Framework (MEF) — это новая библиотека в NETF ramework 4, полезная при создании расширяемых и комбинируемых приложений. MEF позволяет указывать точки, где приложение может быть расширено, предоставлять доступ к службам другим расширяемым приложениям и создавать части, предназначенные для использования расширяемыми приложениями. Она также позволяет легко обнаруживать доступные части на основе метаданных без необходимости загрузки сборок с этими частями.

— Возможности программирования для Office. Благодаря добавлению именованных и дополнительных аргументов, типа dynamic, индексированных свойств и дополнительных модификаторов ref удалось значительно улучшить доступ к COM-интерфейсам, в том числе к API-интерфейсам автоматизации Office.

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

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

— Платформа NET Framework теперь поддерживает файлы с отображением в памяти. С их помощью можно вносить изменения в очень большие файлы и создавать совместно используемую память для межпроцессного взаимодействия.

Заключение

В работе было изложено описание архитектуры, структуры и принципов работы платформы Microsoft NET Framowork. Были рассмотрены преимущества и недостатки данной платформы в сравнении с другими уже существующими решениями. Можно сделать вывод, что платформа Microsoft NET Framework в свое время явилась большим достижением в области разработки программного обеспечения, предоставляя уникальные инновационные возможности.

Также необходимо отметить, что с момента выпуска первой версии платформы NET Framework 1.0 она претерпела некоторые изменения и много дополнений, которые также призваны повысить эффективность разработки. Компания Microsoft продолжит развитие своей платформы и в будущем.

Таким образом, платформа Microsoft NET Framework является прекрасной универсальной платформой для разработки многочисленных типов программных средств, начиная от простых настольных программ, заканчивая сложными корпоративными системами и серверами.

Список использованных источников

1. Рихтер, Джефри. CLRviaC#. Программирование на платформе Microsoft NET Framework 2.0 на языке C#. — Питер, Русская Редакция, 2007 г. — 656 с.

2. Троелсен, Эндрю. С# 2008 и платформа .NET 3.5 Framework. 4-е изд. — М.: Вильямс, 2009. — 1168 с.

3. Рихтер Джефри. Программирование на платформе Microsoft NET Framework. — Питер, Русская Редакция, 2005 г. — 486 с.

4. Новые возможности NET Framework [Электронный ресурс] / MSDN — Электронные данные — Режим доступа: http://msdn.microsoft.com/ru-ru/library/ms171868.aspx.