NET для начинающих. Что такое среда.NET и как она работает? Программирование в.NET Framework

Не имея четкого представления о Microsoft .NET и роли, которую играет в этой новой инициативе Microsoft язык С#, вам будет трудно разобраться в ключевых элементах С#, поддерживаемых платформой Microsoft .NET. Представленный в этой главе обзор технологии Microsoft .NET поможет вам усвоить терминологию, применяемую в этой книге, и понять, почему некоторые элементы языка С# ведут себя так, а не иначе. Если просмотреть в Интернете материалы по Microsoft .NET, можно заметить разнобой в трактовке и употреблении терминов этой технологии. Двусмысленные, а порой и просто противоречивые высказывания мешают уловить суть излагаемого материала. Во многом это объясняется новизной проблемы. Поэтому первым делом я постараюсь разогнать туман вокруг этой темы и разъяснить некоторые термины, связанные с Microsoft .NET.

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

Идея Microsoft .NET в том, чтобы переместить центр внимания вычислительного сообщества из мира, состоящего из различных устройств и Web-узлов, связанных между собой через Интернет, в мир, где высокое качество решений для пользователей обеспечивается совместной работой устройств, служб и компьютеров. Основу Microsoft .NET составляют четыре базовых компонента:

• .NET Building Block Services - средства программного доступа к таким службам, как хранилище файлов (file storage), календарь (calendar), служба аутентификации "Passport.NET";
• ПО для устройств.NET, которое будет выполняться на новых устройствах Интернета;
• средства.NET для работы с пользователями, включающие естественный интерфейс (natural interface), информационные агенты (information agents) и интеллектуальные теги (smart tags) - технологию, которая автоматизирует переход по гиперссылкам к информации, связанной со словами и фразами в документах пользователей;
• инфраструктура.NET, состоящая из.NET Framework, Microsoft Visual Studio.NET, .NET Enterprise Servers и Microsoft Wmdows.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

int main(int argc, char* argv) {

cout " "Hello, World!" " endl;

В начало приложения включен заголовочный файл с объявлением функции 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-код компилируется в машинные команды, специфичные для данного процессора. (На самом деле компилируются только функции, вызываемые впервые.)

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

1. Вы пишете исходный код на С#.
2. Затем вы компилируете его с помощью компилятора языка С# в ЕХЕ-файл.
3. Компилятор создает MSIL-код и помещает в раздел "только-на-чте-ние" выходного файла стандартный РЕ-заголовок (признак машино-независимой выполняемой программы для Win32). Пока все хорошо. Но здесь появляется очень важная деталь: при создании выходного файла компилятор импортирует из CLR функцию _CorExeMain.
4. Когда приложение начинает выполняться, ОС загружает этот РЕ (впрочем, как и обычный РЕ), а также все нужные DLL, в частности, библиотеку, которая экспортирует функцию _CorExeMain (mscoree.dll).
5. Загрузчик ОС выполняет переход в точку входа РЕ, устанавливаемую компилятором. Это ничем не отличается от процедуры загрузки в Windows любого другого РЕ.
   Однако так как ОС не в состоянии выполнить MSIL-код, то фактически в точке входа содержится заглушка, в которой установлена команда перехода к функции jCorExeMain из mscoree.dll.
6. Функция JCorExeMain переходит к выполнению MSIL-кода, помещенного в РЕ.
7. Так как 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.
• Управляемый код, использующий компоненты СОМ По той же причине, по какой нужно вызывать из своего.NET-приложения функции из DLL, написанной на С, вам требуется продолжать поддержку компонентов СОМ. Выход в том, чтобы создать.NET-оболочку для компонента СОМ так, чтобы управляемый клиент полагал, будто он работает с.NET-классом. Этот случай также рассматривается в главе 16.
• Неуправляемый код, использующий.NET-службы Здесь противоположная проблема: вам нужен доступ к.NET из неуправляемого кода. Она решается с помощью обратного подхода: клиент СОМ вводится в заблуждение, будто он работает с СОМ-сервером, который на самом деле является.NET-службой того же вида. Пример такой ситуации также см. в главе 16.

Подведем итоги

Microsoft .NET - это переход на вычислительную модель, в которой устройства, службы и компьютеры работают совместно, обеспечивая создание решений для пользователей. Центром этого перехода являются разработка.NET Framework и CLR (рис. 2-2). .NET Framework содержит библиотеки классов, совместно используемые различными языками, которые компилируются для запуска в среде CLR. Поскольку С# разработан для CLR, вы не сможете решить даже простейшие задачи без CLR и библиотек классов.NET Framework. Понимание особенностей этих технологий является необходимым условием для получения максимальной пользы от С#, а как этого добиться, вы узнаете из основной части этой книги.

Рис 2.2. В.NET Framework включены библиотеки, предназначенные для облегчения взаимодействия между службами, устройствами и компьютерами.

Один из главных принципов.NET можно выразить так: "Изменяйте все, что хотите, используя любые средства". Платформа.NET - это совершенно новая модель для создания приложений для Windows. Перечислим кратко основные положения.NET.

• Все возможности взаимодействия с существующим кодом. Двоичные компоненты СОМ отлично работают вместе с двоичными файлами.NET.
• Полное и абсолютное межъязыковое взаимодействие. В отличие от классического СОМ, в.NET поддерживаются межъязыковое наследование, межъязыковая обработка исключений и межъязыковая отладка.
• Общая среда выполнения для любых приложений.NET вне зависимости от того, на каких языках они были созданы. И что важно, для всех языков используется один и тот же набор встроенных типов данных.
• Библиотека базовых классов, которая скрывает все сложности, связанные с использованием вызовов API, и предлагает законченную объектную модель для всех языков программирования, поддерживающих.NET.
• О запутанных конструкциях СОМ можно забыть! Интерфейсы IClassFactory , IUnknown , код IDL и вариантные типы данных отсутствуют в программах.NET.
• Действительное упрощение процесса развертывания приложения. В среде.NET не надо регистрировать типы в системном реестре. Более того, .NET позволяет разным версиям одного и того же модуля DLL мирно сосуществовать на одном компьютере.

Достоинства

1. Вся платформа.NET основана на единой объектно-ориентированной модели. Что это значит? Дело в том, что все сервисы, интерфейсы и объекты, которые платформа предоставляет разработчику объединены в единую иерархию классов. Другими словами, все, что может вам потребоваться при создании приложений под платформу.NET будет всегда у вас под рукой. Причем, все это сгруппировано очень удобно и интуитивно понятно.
2. Приложение, написанное на любом.NET-совместимом языке является межплатформенным (в идеале). Почему в идеале? Дело в том, что приложение, написанное, скажем, на том же C#, не зависит от платформы, на которой будет выполняться, но зато зависит от наличия платформы.NET. Но согласитесь, что намного легче один раз портировать архитектуру.NET под какую либо систему, после чего без проблем запускать абсолютно любое.NET приложение. Но в настоящий момент платформа.NET портирована только на семейство операционных систем Windows , в том числе на мобильные системы MS Windows mobile.
3. В состав платформы.NET входит т.н. "сборщик мусора", который освобождает ресурсы. Таким образом, приложения защищены от утечки памяти и от необходимости освобождать ресурсы. Это делает программирование более легким и более безопасным.
4. Приложения.NET используют метаданные, что позволяет им не пользоваться системным реестром Windows.
5. Любое.NET приложение является автономным, в том смысле, что не зависит от других программ, в частности от ОС. Установка приложения написанного на одном из.NET языках может быть произведена обычным копированием файлов (исключение составляет создание ярлыков в меня "Пуск" и др. местах).
6. Приложения.NET используют безопасные типы, что повышает их надежность, совместимость и межплатформенность.
7. Приложение, написанное на любом.NET языке взаимодействует с единой моделью обработки ошибок, что значительно упрощает этот нудный процесс.
8. Приложения написанные на разных могут легко взаимодействовать. Например, серверная часть может быть написана на C#, а клиентская на Visual Basic.
9. .NET приложения могут быть сертифицированы на безопасность. Это является особенность промежуточного кода, в который преобразуются все.NET приложения.
10. Абсолютно все ошибки обрабатываются механизмом исключительных ситуаций. Это позволяет избежать разногласия, который иногда возникал при программировании под Win32.
11. Повторное использование кода стало еще удобнее. Это связано с тем, что промежуточный язык MSIL не зависит от языка программирования. Например, вы можете написать программу на C#, а патч к ней писать уже, скажем, на J#.

Недостатки

У любого программного продукта есть свои недостатки, есть они и у платформы.NET. Их нужно тоже знать.

1. Как это часто бывает, за удобство нужно платить скоростью, так и случилось с.NET. Приложения, написанные под платформу.NET работают медленнее, это факт. В некоторых случаях скорость может упасть на 15%, что иногда является неприемлемым (например, при создании 3D приложений, где бьются за каждый FPS). Задержки в выполнении связаны с промежуточным языком MSIL, ведь для того чтобы его скомпилировать в выполняемый файл тоже нужно время. Разумеется, что приложение компилируется не все сразу, а по частям, равномерно при работе программы.
2. Не на любом языке можно создавать.NET приложения. Дело в том, что первоначально.NET "затачивался" под C/JAVA-подобные языки. Это породило некоторые трудности с созданием.NET компиляторов для других языков (особенно экзотических и узкоспециализированных). В результате этого некоторые функции пришлось решать нетривиальными способами, что отрицательно сказалось на производительности. Но постепенно данный недостаток сходит на нет, т.к. разработчики компиляторов поняли важность платформы.NET и стараются сделать для своих языков достойные инструменты.
3. Необходимо наличие библиотеки FrameWork. Данный недостаток устранен с выходом Windows Vista, т.к. данная библиотека встроена в систему по умолчанию.

Можно обратить внимание на то, что достоинств у.NET в сумме получилось больше, чем недостатков. Разумеется, это не является отражением реальности. Это говорит о хорошей маркетинговой кампании проведенной корпорацией Microsoft.

Вопрос, освещённый в данной статье, будет полезен для понимания всей структуры программирования на.net в целом, независимо от языка. Будь то C#, Visual Basiс или J#. Статья ориентирована на начинающих программистов, только осваивающих программирование на.NET.

Что такое.NET?

.Net (читается как «дот нет») – это кросплатформенная среда выполнения приложений. Проще говоря – это то, что позволяет запускаться нашим приложениям в системе Microsoft Windows. Кросплатформенная – означает, что созданное приложение будет работать на всех процессорах и на всех операционных системах семейства Windows (за исключением самых ранних).
Более того! Те, кто уже имел дело с программированием, например, на С++, знает что под процессоры на разной платформе приходится «пересобирать» программы. Например программа, скомпилированная для x64 не будет корректно работать на x86, а программа, собранная для x86 не сможет полностью показать свой потенциал работы на x64 системе.
Тут нам на помощь приходит.Net framework.
.Net Framework – это набор уже скомпилированных библиотек, откуда берутся методы и функции для запуска и разработки приложений. В разработке, на деле, нам придётся просто вызвать уже готовую функцию для того чтобы она заработала. Большинство методов и функций, необходимых программисту, уже скомпилировано и лежит в.net framework внутри системы. И каждая библиотека с функциями лежит в двух вариантах – для x86 и для x64, так что о «пересборке» программы под разные платформы можно забыть! Созданная вами программа будет показывать свой полный потенциал на любой аппаратной («железе») и программной (операционной системе) платформе.

Как это всё работает?

Вспомним, что такое процесс компиляции – это перевод вашего кода, понятного человеку, в бинарный код, понятный компьютеру.

В программировании на.net компиляция и запуск приложений происходит следующим образом:
Код из любого языка преобразовывается в код, написанный на общем языке (Common intermediate language или CIL). Этот язык является языком низшего уровня, похожего по синтаксису на язык ассемблер.
После, этот код передаётся так называемой исполняющей среде (Common language runtime или CLR), которая берёт функции и методы из.net Framework
После этого конечный результат передаётся на процессор и выполняется программа.

CLR – это некая «виртуальная машина», которая собственно и управляет нашими приложениями, написанными для.net.
В ней есть такая занятная штука, как сборщик мусора (Garbage collector). Он подчищает всё ненужное, оставленное программой в оперативной памяти во время выполнения самой программы. То есть, если мы использовали, например, переменную всего один раз в программе, то после обращения к этой переменной, если она больше нигде не задействована – автоматический сборщик мусора её удаляет из оперативной памяти. Это абсолютно безопасно, а главное – это даёт огромный прирост в производительности масштабных и ресурсоёмких приложений. Это очень удобно, ведь в других языках, например в С++ чтобы достичь максимальной скорости работы приложения необходимо вручную удалять обьекты, а в этом случае нужно просчитать когда они не будут востребованы, чтобы их можно было безопасно удалить, чтобы не вызвать ошибку или крах программы.

Также такая схема сборки приложений очень удобна и тем, что происходит «компиляция на лету». То есть не компилируя программу, среда разработки может указать Вам на Ваши ошибки, а это заметно ускоряет процесс разработки.

Что же выделяет.net программирование среди всех?

Первое – это конечно-же относительная лёгкость освоения и работы с языками, так как большинство.Net языков – языки высшего уровня.
Быстрота выполнения конечных исполняемых файлов.
Приложения, написанные на.net сами чистят себя в оперативной памяти, благодаря автоматическому сборщику мусора.
Приложение нужно «собрать» всего один раз, и оно будет работать на всех платформах процессоров и операционных системах семейства Windows. В это же время приложение будет показывать весь свой потенциал скорости, который возможен на определённых процессорах.

Теги: .net, программирование, основы, теория