Урок 1: Знакомство с платформой .NET Framework 4
Урок 1: Знакомство с платформой .NET Framework 4
Урок знакомит c .NET Framework 4, описывает ключевые концепции .NET и инструменты, предоставляемые для упрощения разработки приложений.
Платформа .NET Framework 4
.NET Framework 4 является комплексной платформой разработки, предлагающей быстрый и эффективный способ для создания приложений и услуг. С помощью Visual Studio 2010 разработчики могут использовать .NET Framework 4 для создания широкого спектра решений, работающих на широком диапазоне вычислительных устройств. .NET Framework 4 обеспечивает три основных элемента: общеязыковая среда выполнения (Common Language Runtime, CLR), библиотека классов .NET Framework (.NET Framework Class Library) и коллекция фреймворков для разработки приложений (Development Frameworks).
Среда CLR..NET Framework 4 обеспечивает среду под названием CLR (Common Language Runtime, общеязыковая исполняющая среда). CLR управляет выполнением кода и упрощает процесс разработки, обеспечивая надежную и безопасную среду исполнения, предоставляющую общие услуги, такие как управление памятью, операции, межпроцессорные связи, многопоточность и многие другие функции.
Библиотека классов .NET Framework..NET Framework 4 предоставляет библиотеку классов, которые разработчики могут повторно использовать для создания собственных приложений. Классы составляют основу общей функциональности и предоставляют конструкции, помогающие упростить разработку приложений и избежать необходимости изобретать новую логику. Например, простанство имён System.IO содержит набор классов, позволяющих разработчикам работать с файлами файловой системы Windows. В дополнение к использованию библиотеки классов .NET Framework можно расширить эти классы путем создания собственных библиотек классов.
Фреймворки для разработки приложений..NET Framework 4 обеспечивает несколько фреймворков, которые можно использовать для создания приложений общих типов. Эти фреймворки обеспечивают необходимые компоненты и инфраструктуры для начала разработки соответствующих приложений. Основными фреймворками для разработки приложений являются:
· ASP.NET. Позволяет создавать серверные веб-приложения.
· Windows Presentation Foundation (WPF). Позволяет создавать функционально насыщенные клиентские приложения.
· Windows Communication Foundation (WCF). Позволяет создавать безопасные и надежные сервис-ориентированные приложения.
· Windows Workflow Foundation (WF). Позволяет создавать рабочие процессы (workflow) для выполнения комплексных бизнес-требований современных организаций.
http://msdn.microsoft.com/en-us/library/zw4w595w.aspx
Сборки в .NET
Сборка (assembly) – это абстрактное понятие. Во-первых, это логическая группировка одного или нескольких управляемых модулей и файлов ресурсов. Во-вторых, это самая маленькая единица с точки зрения повторного использования, безопасности и управления версиями. Сборка может состоять из одного (однофайловая сборка) или нескольких (многофайловая сборка) файлов – все зависит от выбранных средств и компиляторов. В мире .NET сборка представляет собой то, что в других условиях называют компонентом. Управляемые модули и файлы ресурсов (или данных) объединяются инструментальным средством, которое и формирует единственный PE-файл, представляющий логическую группировку файлов. При этом PE-файл содержит блок данных, называемый декларацией или манифестом (manifest). Манифест – один из наборов таблиц в метаданных. Эти таблицы описывают файлы, которые формируют сборку, общедоступные экспортируемые типы, реализованные в файлах сборки, а также относящиеся к сборке файлы ресурсов или данных. Если сборка является набором нескольких файлов, один из файлов сборки выбирают для хранения ее манифеста. По умолчанию компиляторы сами выполняют работу по превращению созданного управляемого модуля в сборку, то есть компилятор С# создает управляемый модуль с манифестом, указывающим, что сборка состоит только из одного файла. Итак, в проектах, где есть только один управляемый модуль и нет файлов ресурсов (или данных), сборка и будет управляемым модулем, и не нужно прилагать дополнительных усилий по компоновке приложения. Если же надо сгруппировать набор файлов в сборку, потребуются дополнительные инструменты (вроде компоновщика сборок AL.exe) с соответствующими параметрами командной строки (Рис. 2).
Рис. 2.
Сборка позволяет разделить логический и физический аспекты компонента, поддерживающего повторное использование, безопасность и управление версиями. Разбиение кода и ресурсов на разные файлы отдано полностью на откуп разработчика. Так, редко используемые типы и ресурсы можно вынести в отдельные файлы сборки. Отдельные файлы могут загружаться из интернета по мере надобности. Если файлы никогда не потребуются, они не будут загружаться, что сохранит место на жестком диске и ускорит установку. Сборки позволяют разбить на части процесс развертывания файлов и в то же время рассматривать все файлы как единый набор. Модули сборки также содержат сведения о других сборках, на которые они ссылаются (в том числе номера версий). Эти данные делают сборку самоописываемой (self-describing). Иначе говоря, CLR знает о сборке все, что нужно для ее выполнения. Поэтому развертывать сборки гораздо проще, чем неуправляемые компоненты.
CLR работает со сборками – сначала всегда загружает файл с манифестом, а затем получает из манифеста имена остальных файлов сборки. Некоторые характеристики особенно важны:
· в сборке определены повторно используемые типы;
· сборка помечена номером версии;
· со сборкой может быть связана информация безопасности.
Платформа .NET разделяет сборки на локальные (или сборки со слабыми именами) и глобальные (или сборки с сильными именами). Локальные сборки размещаются в том же каталоге (или подкаталоге), что и клиентское приложение, в котором они используются. Локальные сборки обеспечивают простоту развертывания приложения (все его компоненты сосредоточены в одном месте) и изолированность компонентов. Имя локальной сборки – слабое имя – это имя файла сборки без расширения.
Хотя использование локальных сборок имеет свои преимущества, иногда необходимо сделать сборку общедоступной. До появления платформы .NET доминировал подход, при котором код общих библиотек помещался в системный каталог простым копированием фалов при установке. Такой подход привел к проблеме, известной как «ад DLL» (DLL Hell). Инсталлируемое приложение могло заменить общую библиотеку новой версией, при этом другие приложения, ориентированные на старую версию библиотеки, переставали работать. Для устранения «ада DLL» в платформе .NET используется специальное защищенное хранилище сборок (Global Assembly Cache, GAC).
Сборки, помещаемые в GAC, должны удовлетворять определенным условиям. Во-первых, такие глобальные сборки должны иметь цифровую подпись. Это исключает подмену сборок злоумышленниками. Во-вторых, для глобальных сборок отслеживаются версии и языковые культуры. Допустимой является ситуация, когда в GAC находятся разные версии одной и той же сборки, используемые разными приложениями.
Сборка, помещенная в GAC, получает сильное имя. Использование сильного имени является признаком, по которому среда исполнения понимает, что речь идет не о локальной сборке, а о сборке из GAC. Сильное имя включает: имя главного файла сборки (без расширения), версию сборки, указание о региональной принадлежности сборки и маркер открытого ключа сборки:
NameAssembly,Version=1.1.0.0,Culture=en,PublicKeyToken=874e23ab874e23ab
Номер версии сборки состоит из следующих компонент:
· Главного номера версии (Major version number)
· Второстепенного номера версии (Minor version number)
· Номера сборки (Build number)
· Номера версии (Revision number)
Часть Major является обязательной. Любая другая часть может быть опущена (в этом случае она полагается равной нулю). Часть Revision можно задать как *, тогда компилятор генерирует ее как количество секунд, прошедших с полуночи, деленное на два. Часть Build также можно задать как *. Тогда для нее будет использовано количество дней, прошедших с 1 февраля 2000 года.
Как правило, когда сборка представляется клиентам как часть приложения, следует убедится, что она содержит информацию о версии, и что сборка подписана (signed). Управление версиями сборок важно, поскольку, в конечном счете, все строящиеся приложения будут иметь несколько выпусков (releases). Информация о версии сможет помочь определить, какие версии у клиентов уже есть, и позволит выполнять необходимые действия по обновлению приложений. Аналогичным образом информация о версии также может помочь при документировании и исправление ошибок. Подписание сборки важно, потому что оно гарантирует, что сборка не может быть легко изменена или заменена альтернативной реализацией от злоумышленников, и так как дает сборке строгое имя. Такая информация, как версия сборки и идентичность безопасности хранятся, как и метаданные, в манифесте сборки. Манифест также содержит метаданные, описывающие сферу сборки и любые ссылки на классы и ресурсы.
Подписание сборки (Assembly Signing) является важным шагом, который должен включаться в процесс разработки, поскольку это обеспечивает следующие преимущества:
· Защищает сборки от модификаций.
· Позволяет включать подписанную сборку в глобальный кэш сборок (GAC), позволяя ее использовать другим приложениям.
· Гарантирует, что имя сборки является уникальным.
Для подписи сборки строгим именем необходимо иметь пару ключей – открытый и закрытый. Эта пара открытого и закрытого ключей шифрования используется в процессе компиляции для создания сборки со строгим именем. Пару ключей можно создать с помощью инструмента для работы со строгими именами (Sn.exe). Файлы пары ключей обычно имеют расширение .snk. С помощью следующей команды создается новая пара случайных ключей, которая сохраняется в файле keyPair.snk.
sn -k keyPair.snk
Параметр -k указывает на создание ключей. Следующая команда отображает открытый ключ и его маркер, которые содержатся в файле keyPair.snk.
sn -tp keyPair.snk
Если необходима отложенная подпись сборки и имеется контроль над всей парой ключей, для создания пары ключей и получения из нее открытого ключа для записи его в отдельный файл можно использовать следующие команды. Сначала создается пара ключей:
sn -k keyPair.snk
Затем выполняется извлечение открытого ключа из пары и копирование его в отдельный файл:
sn -p keyPair.snk publicKey.snk
После создания пары ключей необходимо поместить файл туда, где его смогут найти средства подписи строгого имени.
Для подписи сборки строгим именем, можно использовать компоновщик сборок (Assembly Linker, Al.exe) ), входящий в пакет SDK для Windows, специальные атрибуты уровня сборки [AssemblyKeyFile] или [AssemblyKeyName] (в зависимости от того, где находится используемый файл ключа) либо использовать ключ компилятора командной строки /keyfile.
После подписания сборку можно поместить в GAC. Для этого можно использовать утилиту gacutil.exe, входящую в состав .NET Framework SDK. При использовании ключа /i сборка помещается в GAC, а ключ /u удаляет сборку из GAC:
gacutil.exe /i NameAssambly.dll
В результате сборка с именем NameAssambly будет помещена в GAC, при этом ее сильное имя (для ссылки в программах) будет иметь вид:
NameAssambly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ff8e56aa9648cb91
Если необходимо указать версию сборки, используется атрибут [AssemblyVersion].
http://go.microsoft.com/fwlink/?LinkId=192879
http://go.microsoft.com/fwlink/?LinkId=192880
http://go.microsoft.com/fwlink/?LinkId=192881
Классы и пространства имен
Visual C# является объектно-ориентированным языком, использующим классы и пространства имен для разделения приложения .NET Framework на модули, как на логические компоненты.
Класс по существу чертеж, определяющий характеристики сущности, и включает в себя свойства, определяющие типы данных, которые может содержать объект, и методы, описывающие поведение объекта. Пространство имен представляет собой логический набор классов. Классы хранятся в сборках, а пространство имен является средством для устранения неоднозначности классов, которые могут иметь одинаковые имена в различных сборках. Например, пространство имен System.IO включает в себя следующие классы, которые позволяют управлять файловой системой Windows. Однако, можно создать классы с таким же названием и в собственном пространстве имен:
· File
· FileInfo
· Directory
· DirectoryInfo
· Path
Для использования класса, определенного в .NET Framework, следует выполнить следующие задачи:
1. Добавить ссылку на сборку, которая содержит скомпилированный код для класса.
2. Добавить пространство имен, которое содержит класс, в область видимости.
При разработке приложения .NET Framework для записи текста в новый файл в файловой системе Windows, импортируется пространство имен System.IO, для этого используется ключевое слово using[2], а затем используется метод WriteAllText класса File.
using System;
using System.IO;
using System.Collections;
Структура приложения WPF
При создании нового приложения WPF с помощью шаблона приложения WPF Visual Studio 2010 выполняет следующие задачи:
· Создает новый файл с расширением .сsproj для представления проекта WPF и структурирует в проекте WPF все компоненты по умолчанию.
· Добавляет ссылки на необходимые сборки, включая сборки PresentationCore, PresentationFramework, System, System.Core и System.Xaml.
· Создает файл разметки App.xaml и файл кода (code-behind) App.xaml.cs, которые можно использовать для определения ресурсов и функциональности уровня приложения.
· Создает файл разметки MainWindow.xaml и файл кода (code-behind) MainWindow.xaml.cs, которые можно использовать в качестве отправной точки для создания первого окна WPF.
В следующем примере показана разметка по умолчанию, создаваемая в файле разметки MainWindow.xaml.
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
</Grid>
</Window>
Эта разметка определяет простое окно с названием, шириной и высотой по умолчанию. Изменить эти свойства можно, редактируя код XAML, или с помощью окна свойств в Visual Studio. Можно также изменить эти свойства динамически, с помощью кода при запуске приложения.
Элемент управления (control) Grid регулирует расположение элементов управления, которые добавляются к окну. Если нужно использовать альтернативное расположение, можно заменить разметку для элемента управления Grid другим элеметном управления.
В следующем примере показана разметка по умолчанию, создаваемая в файле App.xaml.
<Application x:Class="WpfApplication1.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml">
<Application.Resources>
</Application.Resources>
</Application>
Следует отметить, что элемент Application содержит атрибут StartupUri, который указывает на окно, которое будет открываться при запуске приложения.
Как файл разметки App.xaml, так и файл разметки MainWindow.xaml используют XAML для представления ресурсов и элементов пользовательского интерфейса. XAML является языком разметки для декларативного программирования приложений. Использование разметки XAML во время разработки позволяет отделить дизайн пользовательского интерфейса от логики приложения, которая хранится в файлах кода. XAML непосредственно представляет экземпляры управляемых объектов.
События в приложениях WPF
При создании WPF, ASP.NET и Windows Forms приложений Visual Studio 2010, создаюся приложения, управляемые событиями, т.е. выполняющие код в ответ на события. Любая создаваемая форма и элемент управления предоставляют предопределенный набор событий. Когда происходит одно из этих событий, и существует код, связанный с обработчиком этого события, код вызывается.
Указать события, на которые реагирует элемент управления, можно во время разработки путем редактирования XAML определения элемента управления (указав событие и имя метода обработки события для запуска при наступлении события). Кроме того, можно использовать вкладку Events в окне Properties (эта техника автоматически изменяет XAML определение элемента управления). Необходимо предоставить методы, обрабатывающие события с помощью кода в файле кода.
Следующие примеры кода показывают XAML разметку для элемента управления Button с обработчиком события Click и код C#, определяющий обработчик событий. Когда пользователь нажимает кнопку, вызывается метод myButton_Click. Параметры метода myButton_Click определяются WPF и заполняются сведениями о кнопке и событии во время выполнения.
[XAML control declaration]
<Button Name="myButton" Click="myButton_Click">ClickMe</Button>
[Visual C# event handler]
private void myButton_Click(object sender, RoutedEventArgs e)
{
// Code to do something goes here.
}
В следующем примере показано определение обработчика события закрытия окна для элемента управления Window.
[XAML control declaration]
<Window x:Class="WpfApplication1.MainWindow" Name="myWindow"
xmlns="..."
xmlns:x="..."
Title="MainWindow" Height="350" Width="525" Closing="myWindow_Closing">
</Window>
[Visual C# event handler]
private void myWindow_Closing(object sender,System.ComponentModel.CancelEventArgs e)
{
// Code to do something goes here.
}
http://msdn.microsoft.com/en-us/library/ms753115(VS.100).aspx
XML комментарии
В Visual Studio 2010 можно добавить комментарии к исходному коду, который будет обработан в файл XML. Комментарии могут быть использованы для создания справочной документации по классу, а также для поддержки IntelliSense. Для того, чтобы система IntelliSense и компилятор документации могли понимать и обрабатывать комментарии, необходимо, чтобы они писались в соответствии с определенным форматом.
Первым признаком того, что комментарий является документационным, являются три слеша (///) в его начале. Visual Studio распознает по этому признаку документационный комментарий и автоматически генерирует для него соответствующую заготовку. После генерации заготовки разработчику достаточно лишь заполнить содержимое тегов и документационный комментарий готов. В следующем примере класс Hello содержит теги документации <summary> и <seealso>.
/// <summary> Класс Hello выводит на экран приветствие
/// </summary>
public class Hello
{
/// <summary> Использован консольный ввод-вывод. Для большей информации о
/// WriteLine<seealso cref="System.Console.WriteLine()"/>
/// </summary>
public static void Main()
{
Console.WriteLine("Hello World");
}
}
Встроенные комментарии являются частью стандарта Visual C#, в то время как XML комментарии это расширение Microsoft и, как правило, они используются средствами сторонних производителей, например, таких как Sandcastle Help File Builder.
http://go.microsoft.com/fwlink/?LinkId=192887
Общие теги XML комментариев
Для документирования приложения существует несколько тегов XML, однако можно также создавать свои собственные пользовательские метки. В следующей таблице приведены XML-теги, используемые при работе с документационными комментариями, и их назначение:
Tег | Назначение |
<c> | Помечает текст как программный код. |
<exception> | Документирует класс исключения. |
<summary> … </summary> | Предоставляет краткое описание. Для более подробного описания используются теги <remarks>. |
<remarks> … </remarks> | Содержит подробное описание. Этот тег может содержать вложенные разделы (пункты), списки и другие типы тегов. |
<example> … </example> | Предоставляет пример того, как метод, свойство или другой член библиотеки должен быть использован. Этот тег часто связано с использованием вложенных тегов <code>. |
<code> … </code> | Указывает, что прилагаемый текст является кодом приложения. |
<returns> … </returns> | Документирует возвращаемое значение и тип метода. |
<include> | Включает комментарии из другого файла документации. |
<list> | Описывает список. |
<param> | Задает описание передаваемого в метод аргумента. Имеет атрибут name, задающий имя аргумента. |
<paramref> | Указывает, что слово является параметром метода. |
<permission> | Документирует доступ к члену класса. |
<see> | Предоставляет перекрестную ссылку на другой параметр. |
<seealso> | Задает раздел «Смотри также». |
<value> | Описывает свойство. |
Следует отметить, что если речь не идет о создании полноценной библиотеки классов, которую предполагается распространять как самостоятельный программный продукт и которую необходимо снабдить максимально подробной помощью, сопоставимой по возможностям с MSDN, в использовании всех этих тегов нет необходимости. В повседневной жизни разработчику необходимо задавать лишь минимальное описание созданного им программного кода, для чего вполне достаточно ограничиться знанием тегов <summary> и <param>, отображаемых в качестве подсказок системой IntelliSense, а также тега <returns>, поскольку при задании описания для методов, возвращающих значение, он генерируется автоматически и его содержимое отображается в Object Browser.
В теле программы документировать с использованием тегов <summary>, <param> и <returns> необходимо, как минимум:
· все классы, структуры, перечисления и интерфейсы;
· все не закрытые (private) поля, свойства и методы классов;
· все элементы перечислений;
· закрытые поля, свойства и методы в том случае, если тело класса имеет достаточно большой размер, или допускается хотя бы мысль о возможности его дальнейшей модификации.
При разработке коммерческих библиотекнеобходимо проводить полноценное документирование с использованием всего спектра тегов. Например, после следующего документирования класса Triangle система IntelliSense начнет отображать документационные комментарии в качестве подсказок (Рис. 8).
/// <summary>
/// Класс, описывающий треугольник по трем сторонам
/// </summary>
public class Triangle
{
private double a;
private double b;
private double c;
/// <summary>
/// Конструктор
/// </summary>
/// <param name="a"></param>
/// <param name="b"></param>
/// <param name="c"></param>
public Triangle(double a, double b, double c)
{
this.a = a;
this.b = b;
this.c = c;
}
/// <summary>
/// Определение площади треугольника по формуле Герона
/// </summary>
/// <returns>площадь треугольника</returns>
public double GetArea()
{
double p = (a + b + c) / 2;
double s = Math.Sqrt(p * (p - a) * (p - b) * (p - c));
return s;
}
}
Рис. 8.
Аналогично, при работе с объектом класса, для его методов и их аргументов также будут отображаться подсказки (Рис. 9).
Рис. 9.
http://go.microsoft.com/fwlink/?LinkId=192888
Использование Debug Windows
Visual Studio 2010 включает в себя несколько окон, которые можно использовать для отладки приложений. Эти окна доступны во время выполнения, в основном, в режиме прерывания (Рис. 13).
Рис. 13.
В таблице приведены некоторые из наиболее часто используемых окон отладки в Visual Studio 2010.
Окно | Описание |
QuickWatch | Это модальное окно, которое позволяет вычислять переменные и выражения. Для его использования нужно набрать имена переменных или выражений в поле Expression, а затем нажать кнопку Reevaluate, чтобы посмотреть значение и тип переменной или результата выражения. Чтобы закрыть окно QuickWatch нужно нажать Close. |
Locals | Это окно позволяет просматривать и редактировать локальные (в пределах области видимости) переменные. Можно расширить переменные, просмотреть члены и редактировать содержание некоторых переменных в столбцах Value. |
Immediate | Это окно позволяет вычислять выражения, выполнять операторы и распечатывать значения переменных. Можно использовать это окно в контексте команды Visual Studio 2010 Debug.Print, чтобы печатать значения переменной или выражения. |
Output | В этом окне можно просматривать ошибки и информационные сообщения. Одним из основных видов использования этого окна, является посмотр следов приложения с помощью метода System.Diagnostics.Debug.WriteLine(). |
Memory | Это окно позволяет просмотреть и отредактировать содержимое памяти, который использует приложение. Это функция может заставить приложение вести себя непредсказуемо, если только не использовать ее с осторожностью. |
Call Stack | Это окно позволяет просматривать стек вызовов методов, которые используются для достижения текущего местоположения кода. Текущая позиция отображается в верхней части окна, а ниже показан ряд вызовов, которые обрабатываются приложением для достижения этого расположения. |
Modules | Это окно позволяет просматривать информацию о модулях (сборках и исполняемых файлах), которые использует приложение. Каждый модуль перечисляется вместе с его местоположением, версией и другой информацией. |
Processes | В этом окне можно просматривать информацию о процессах, к которым присоединен отладчик. |
Threads | В этом окне можно проверять и контролировать потоки приложения. |
[1] .NET Reflector – платная утилита для Microsoft .NET, комбинирующая браузер классов, статический анализатор и декомпилятор, изначально написанная Lutz Roeder. 20 августа 2008 Red Gate Software объявили, что они берут ответственность за дальнейшую разработку программы. MSDN Magazine назвал ее одной из десяти «Must-Have» утилит для разработчиков.
[2] Использование оператора using просто удобство, без которого можно обойтись. Например, вместо имени Console можно использовать полностью уточненное имя System.Console.
[3] Инструмент Sandcastle не предусмотрен в рамках Visual Studio, доступен на веб-сайте CodePlex (http://shfb.codeplex.com, http://www.codeplex.com/).
Урок 1: Знакомство с платформой .NET Framework 4
Урок знакомит c .NET Framework 4, описывает ключевые концепции .NET и инструменты, предоставляемые для упрощения разработки приложений.
Платформа .NET Framework 4
.NET Framework 4 является комплексной платформой разработки, предлагающей быстрый и эффективный способ для создания приложений и услуг. С помощью Visual Studio 2010 разработчики могут использовать .NET Framework 4 для создания широкого спектра решений, работающих на широком диапазоне вычислительных устройств. .NET Framework 4 обеспечивает три основных элемента: общеязыковая среда выполнения (Common Language Runtime, CLR), библиотека классов .NET Framework (.NET Framework Class Library) и коллекция фреймворков для разработки приложений (Development Frameworks).
Среда CLR..NET Framework 4 обеспечивает среду под названием CLR (Common Language Runtime, общеязыковая исполняющая среда). CLR управляет выполнением кода и упрощает процесс разработки, обеспечивая надежную и безопасную среду исполнения, предоставляющую общие услуги, такие как управление памятью, операции, межпроцессорные связи, многопоточность и многие другие функции.
Библиотека классов .NET Framework..NET Framework 4 предоставляет библиотеку классов, которые разработчики могут повторно использовать для создания собственных приложений. Классы составляют основу общей функциональности и предоставляют конструкции, помогающие упростить разработку приложений и избежать необходимости изобретать новую логику. Например, простанство имён System.IO содержит набор классов, позволяющих разработчикам работать с файлами файловой системы Windows. В дополнение к использованию библиотеки классов .NET Framework можно расширить эти классы путем создания собственных библиотек классов.
Фреймворки для разработки приложений..NET Framework 4 обеспечивает несколько фреймворков, которые можно использовать для создания приложений общих типов. Эти фреймворки обеспечивают необходимые компоненты и инфраструктуры для начала разработки соответствующих приложений. Основными фреймворками для разработки приложений являются:
· ASP.NET. Позволяет создавать серверные веб-приложения.
· Windows Presentation Foundation (WPF). Позволяет создавать функционально насыщенные клиентские приложения.
· Windows Communication Foundation (WCF). Позволяет создавать безопасные и надежные сервис-ориентированные приложения.
· Windows Workflow Foundation (WF). Позволяет создавать рабочие процессы (workflow) для выполнения комплексных бизнес-требований современных организаций.
http://msdn.microsoft.com/en-us/library/zw4w595w.aspx