• Официальный старт новой платформы Microsoft .NET
• Новая операционная среда
• Библиотека базовых классов
• .NET и COM-объекты
• Common Language Runtime
• Что впереди

Официальный старт новой платформы Microsoft .NET

13 февраля состоялся официальный старт новой платформы Microsoft .NET — на грандиозной презентации в Сан-Франциско были представлены рабочие версии двух главных ее элементов: операционной среды .NET Framework и инструментального набора Visual Studio .NET. Что нового предлагают эти средства, что они сулят разработчикам и пользователям?

К сожалению, несмотря на обилие публикаций о данных продуктах, многое остается весьма туманным. Самое удивительное, что “дымовую завесу” активно поддерживает и сама Microsoft. Например, в официальном пресс-релизе по поводу выхода новинок написано, что это “краеугольные камни в реализации стратегии Microsoft в отношении XML Web Services”. Хотя даже при поверхностном взгляде видно, что .NET Framework и VS.NET никак явно не связаны с этими сервисами.

Не говоря уже о том, что технология XML Web Services базируется на отрытых стандартах и является платформно-независимой. В этой связи представляется полезным внимательнее разобраться с архитектурными решениями, лежащими в основе одного из базовых элементов Microsoft .NET, — операционной среды .NET Framework.

Новая операционная среда

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

Хотелось бы отметить, что термин “платформа” мы обычно применяем в двух разных смыслах. С одной стороны, это “концепция” (идеи, спецификации и т. д.), с другой — набор вполне конкретных объектов (файлов, документации и пр.). Эта двойственность в полной мере относится к .NET Framework.

Рис. 1 Структурная схема .NET Framework

В настоящее время поставляется программный набор .NET Framework SDK 1.0, в который кроме собственно модулей операционной среды входят документация, а также ряд автономных компиляторов — VB, C# (т. е. разработку простых .NET-приложений можно вести и без визуальной среды Visual Studio .NET). Пакет устанавливается поверх Windows NT 4.0, 2000 или XP в подкаталог WINNT\Microsoft.NET\Framework\ v1.0.XXX. Он распространяется бесплатно (его можно загрузить с Web-сайта Microsoft) или в составе VS.NET.

.NET Framework состоит из двух главных компонентов: библиотеки базовых классов и CLR (Common Language Runtime — общая для языков среда исполнения NET-приложений), которые соответственно предназначены для решения следующих задач:

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

В этой среде ведется разработка и исполнение программ. Главным инструментом создания приложений является конечно же Visual Studio .NET, в котором каждый из языков программирования взаимодействует с .NET Framework через общий интерфейс. В состав VS.NET входит несколько языков Microsoft, среди которых важнейшая роль отводится C/C++, C# и VB.

В саму среду разработки вошли средства, ранее реализованные в виде пакета Visual InterDev. VS.NET позволяет создавать .NET-приложения различных типов, но все они являются теми или иными модификациями трех базовых вариантов — Console Application, Windows Application и Class Library.

Создание универсальной среды разработки и общих базовых функций предопределило то, что отныне все языки программирования Microsoft поставляются в виде единого пакета (например, отдельного продукта VB.NET уже нет). Кроме того, это сильно упрощает подключение к ней (в виде дополнительных модулей Add-Ins) других языков программирования. В настоящее время о создании таких средств (Cobol, Fortran, Perl и пр.) объявили многие разработчики. Кроме того, некоторые поставщики (в частности, Borland) предлагают собственные интегрированные средства программирования для .NET.

Представители Microsoft, сравнивая .NET с конкурирующей Java 2 Platform, часто подчеркивают, что корпорация вовсе не стремится доминировать в области языков программирования, предоставляя всем разработчикам равные возможности (прозрачный намек на Sun). В какой-то степени это справедливо (хотя “льготные” условия для Microsoft заложены в .NET изначально), но самое важное заключается совсем в другом: все независимые инструменты будут только в среде .NET Framework.

Библиотека базовых классов

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

Впрочем, говорить о разных наборах функций для различных языков в “до .NET-овские” времена можно с большой долей условности. Та же Microsoft для QuickBasic и QuickC использовала единые внутренние конструкции и библиотеки подпрограмм еще в конце 80-х годов. А компиляторы VB изначально были реализованы с помощью промежуточного кода на Си.

Такая унификация системы разработки автоматически нивелирует функциональные возможности разных языков, поэтому выбор инструмента в значительной степени зависит от пристрастия конкретного программиста к тому или иному синтаксису. Это сегодня особенно хорошо видно на примере VB.NET и C#. Однако тут стоит отметить, что Microsoft осталась верна принципу “разделяй и властвуй” — в ее языках сохранены искусственные различия, предопределяющие необходимость применения различных средств для решения разных задач.

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

Кроме того, базовые функции перестали быть принадлежностью пользовательских приложений и превратились в неотъемлемый компонент операционной системы (ранее принадлежностью ОС были только API-функции).

Например, библиотеки MFC VC++ — это набор статических объектных модулей, которые подключаются к приложению на этапе компоновки исполняемого модуля программы и становятся при этом его составной частью. А .NET Class Library — динамические библиотеки классов, являющиеся компонентом .NET Framework.

Рис. 2 Состав библиотек базовых классов
О достоинствах применения объектных библиотек (LIB) и библиотек классов (DLL) отныне можно говорить лишь с точки зрения академического интереса. Ведь разработчики .NET лишены возможности выбора (за исключением тех, кто пишет на C/C++, которые занимают особое положение в средствах разработки .NET). Очевидно, что привязка прикладной программы к платформе .NET существенно возросла по сравнению с традиционной Windows.

Библиотека классов .NET реализована в виде набора DLL (сейчас их 20), имена которых начинаются с идентификатора System (рис. 2). Кстати, из рисунка хорошо видно, что за поддержку технологии Web Services отвечает лишь одна из DLL.

Сразу нужно подчеркнуть, что хотя данные файлы имеют расширение DLL, — речь идет о новом типе библиотек, отличном от обычных DLL и ActiveX (COM) DLL (непонятно, зачем нужно использовать одно расширение для файлов разных типов — это приводит к путанице).

.NET и COM-объекты

Class Library — лишь базовый набор функций, который можно расширять за счет дополнительных библиотек .NET-объектов, создаваемых независимыми разработчиками. В несколько упрощенной форме различие между системными и дополнительными библиотеками заключается в том, что первые автоматически доступны для приложений (как часть ОС!), а вторые нужно подключать индивидуально.

С точки зрения пользователя (но лишь на первый взгляд), .NET-объекты представляют собой модернизированный вариант COM с двумя видимыми отличиями: в них используются иерархическая система имен объектов и иной порядок объединения программных компонентов в приложении.

В отличие от плоского идентификатора типа “ИмяПриложения.ИмяКласса” в COM, теперь можно использовать “ИмяПриложения.Имя1.Имя2....ИмяКласса”. Если ранее, например в VB 6.0, модуль класса мог содержать только один класс, то теперь (VB.NET) один модуль может включать иерархию классов:

Public Class Class0 ‘ объект нулевого уровня

‘ код класса

End Class

Namespace Name1 ‘ объекты первого уровня

Public Class Class1

End Class

Public Class Class2

End Class

Namespace Name2 ‘ объекты второго уровня

Public Class Class2

End Class

End Namespace

End Namespace

Соответственно полные имена объектов для этого модуля, включенного в MyClass.dll, будут выглядеть следующим образом:

MyClass.Class0

MyClass.Name1.Class1

MyClass.Name1.Class2

MyClass.Name1.Name2.Class2

Для использования сокращенных имен объектов допускается импорт пространств имен:

Imports MyClass

Imports MyClass.Name1

Тогда в программе к объектам можно обращаться с такими именами: Class0, Class1, Class2, Name2.Class2. Понятно, что использовать импорт пространств имен нужно очень аккуратно, чтобы не возникло противоречий идентификаторов классов.

В приведенном выше примере мы не можем импортировать MyClass.Name1.Name2, так как возникнет неопределенность для имени Class2 (оно встречается дважды в разных пространствах имен).

Объединение отдельных .NET-компонентов в одно приложение непосредственно связано с новым понятием “сборка” (Assembly). Как известно, с контролем версий в COM дело обстояло, мягко говоря, не самым лучшим образом. Фактически поддержка совместимости версий была полностью возложена на разработчика COM-объектов.

Технология .NET Assembly призвана решить все эти проблемы, известные под названием DLL Hell (ад DLL). В упрощенном виде идея заключается в переносе процедур регистрации объектов из системного Реестра на уровень отдельных приложений.

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

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

Что касается решения проблем DLL Hell, то, помимо жесткого контроля за используемыми версиями, оно включает также простое создание локальных копий внешних компонентов внутри каталога с данным приложением (т. е. сборка будет включать не ссылку на компонент, а сам компонент).

Common Language Runtime

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

Фактически CLR исполняет программы, написанные только на одном стандартном языке Microsoft Intermediate Language (MSIL), который в свою очередь соответствует спецификациям Common Language Specification. Кстати, MSIL — это вполне реальный язык программирования (с использованием синтаксиса в стиле “Си”), на нем можно писать исходные модули и транслировать их с помощью автономного компилятора, который входит в состав .NET Framework SDK*.

* На самом деле точным аналогом Java (с точки зрения его роли для платформы) является именно MSIL — язык платформы .NET нижнего уровня, “.NET-Assembler”.

Все же остальные языки, в том числе и C#, — это языки верхнего уровня, платформно-независимые. Можно было бы легко включить MSIL в визуальную среду Visual Studio .NET, но, видимо, Microsoft решила не дразнить гусей, чтобы иметь возможность говорить о “равных правах для всех поставщиков средств программирования”.

Соответственно задача всех средств разработки .NET-приложений заключается в формировании результирующего исполняемого модуля на MSIL, но только реализованного уже в виде двоичного байт-кода.

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

Первый вариант является основным, при этом применяется так называемый Just-In-Time — компилятор, который выполняет преобразование MSIL в машинный код по мере обращения к соответствующим процедурам (т. е. неиспользуемые фрагменты программы вовсе не компилируются). Данный подход тоже достаточно известен, он, в частности, уже несколько лет используется в платформе “1С:Предприятие”.

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

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

Программы на языке MSIL создают так называемый “управляемый код” (managed code). Это означает, что CLR не просто преобразует MSIL в машинные инструкции, а выполняет эти действия с учетом внешних установок.

Например, Модуль1 может задать собственный набор прав, предоставляемый вызываемому им Модулю 2, запретив, в частности, любые операции коррекции файлов. То есть в CLR мы видим реализацию идей Интернет-браузеров, которые предоставляют промежуточную среду выполнения программ, но только с более высоким уровнем управляемости правами по сравнению с обычной OC.

Microsoft предлагает три языка программирования в составе Visual Studio .NET для формирования “управляемого кода” (создания .NET-приложений) — VB, C# и специальный вариант С++ With Managed Extensions. Как видно из этого списка, Visual C+ занимает совершенно особую позицию в средствах разработки Microsoft: с его помощью можно писать как традиционные Windows-приложения с “неуправляемым кодом” (unmanaged code), так и .NET-приложения, исполняемые в среде CLR.

Что касается платформной независимости, то вроде бы CLR имеет все предпосылки для этого, ведь нужен лишь JIT-компилятор (как это делается для Java). Но я не разделяю оптимизма некоторых экспертов, считающих возможным появление в ближайшее время подобных средств, например, для Linux. Во-первых, в CLR изначально задействованы базовые службы Windows.

Во-вторых, Microsoft совершенно иначе, чем Java-сообщество, трактует понятие многоплатформности: JIT-компиляторы появятся для разных типов аппаратуры (карманные ПК, сотовые телефоны и пр.), но работать они будут только в среде Windows .NET!

Что впереди

Сегодня .NET Framework — это некая дополнительная операционная среда, устанавливаемая в Windows в качестве автономного программного компонента. Нет сомнений, что она станет неотъемлемой частью будущей версии Windows (к выпуску Windows XP ее не успели закончить). Тем не менее еще несколько лет пользователи Windows будут иметь возможность работать как в режиме “Win API + COM”, так и .NET.

Но потом им придется забыть о “старом, добром Windows” и работать исключительно в режиме “управляемого кода” в среде CLR. Это произойдет гораздо быстрее, чем в период “от DOS к Windows”.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Microsoft
Отправить ссылку на страницу по e-mail