Журнал LinuxFormat - перейти на главную

LXF145:Mono

Материал из Linuxformat
Перейти к: навигация, поиск

Содержание

Кроссплатформенные приложения

Mono Посмотрим, как Mono, среда времени выполнения и разработки .NET, конкурирует с предложениями от Microsoft.
Архитектура .NET

Приложение .NET вступает в жизнь как исходный файл на C#, VB или любом другом языке, имеющем компилятор .NET. Компилятор генерирует сборки (файлы EXE или DLL) в виде кода на языке Common Intermediate Language (промежуточный язык обмена, по типу байт-кода Java), а тот на стадии исполнения преобразуется в машинный код компилятором «на лету» [JIT – just-in-time] в среде времени выполнения .NET. Загрузчик сборки также загружает заранее определенные сборки, нужные приложению, из библиотеки классов .NET.

Постоянные читатели этой рубрики (а мое самолюбие уверяет меня, что они есть) знают, что я зарабатываю на хлеб преподаванием Linux, но у меня есть и мрачная тайна – я преподаю еще и C# и .NET! Меня часто спрашивают, почему я нахожусь и в лагере открытого ПО, и в лагере Microsoft, и, честно говоря, откажись я от одного или от другого, это бы освободило немного столь необходимого места в моей голове. Но и то, и другое приносит работу, и отказаться от нее трудно.

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

Основной язык разработки в .NET – C#. Это объектно-ориентированный язык, во многом схожий с Java и синтаксически тесно связанный с семейством языков C. Популярен также Visual Basic, и существуют компиляторы .NET для множества других языков, включая Perl, PHP, Python, Fortran, COBOL и другие. Эти компиляторы формируют код на промежуточном языке (точно так же, как компиляторы Java формируют байт-код Java), а в среде .NET есть компилятор, который «на лету» преобразует промежуточный язык в машинный код. Эта архитектура позволяет довольно легко интегрировать различные языки. Можно писать разные классы на разных языках (в одном и том же приложении) и даже написать базовый класс (например) на C# и унаследоваться от него в производном классе, написанном на VB.

Подавляющее большинство разработчиков пишет приложения в .NET, пользуясь средствами Windows как для разработки (Microsoft Visual Studio), так и для развертывания. Однако растет группа людей, использующих средства разработки Linux (MonoDevelop) и среду времени выполнения .NET в Linux (Mono). Приложения Linux, использующие Mono, о которых вы могли слышать, включают Tomboy (менеджер заметок), Beagle (средство индексирования и поиска), F-Spot (программа для управления фотографиями) и Banshee (медиа-проигрыватель). Гораздо более полный список см. на сайте http://www.mono-project.com/Software.

Мартышкина возня

Mono – по-испански «обезьяна» (отсюда и выбор логотипа). Его создали Мигель де Икаса [Miguel de Icaza] и Нат Фридман [Nat Friedman], которые тогда (на рубеже тысячелетия) работали в Ximian, компании, впоследствии приобретенной Novell. Ximian – другой вариант написания слова «simian» (обезьяньи), и на логотипе самой компании изображен силуэт обезьяны. Это также объясняет название Bonobo (вид крупных обезьян) и логотип Gnome в виде обезьяньего следа. Пожалуй, назову-ка я очередной мой шедевр в .NET «Шерстистый гиббон».

Проводим сравнения

С тех пор, как я в последний раз интересовался Mono, прошло несколько лет; тогда компилятор C# работал, но все средства развертывания были на базе командной строки, библиотека классов была ограниченной, и казалось, что далеко от консольного приложения «Hello World» здесь не уйдешь. Времена явно изменились, и в этой статье я попытался дать ответ на два общих вопроса. Первый – выдерживает ли среда Mono сравнение со средой .NET от Microsoft? Например, пригодны ли сборки, созданные в Windows, для запуска в Linux? Второй – чем отличается опыт разработчика .NET в Windows и Linux? Иначе говоря, чем отличаются MonoDevelop и Visual Studio? Я сознательно ушел от обсуждения любых идеологических вопросов насчет разработчиков свободного ПО, пользующихся технологией Microsoft, маркетинговых стратегий Microsoft и опасений о патентах, связанных с .NET.

Сначала я понадеялся воспользоваться SLED или OpenSUSE: как-никак, Novell – спонсор Mono, и можно ожидать хорошей поддержки собственным брендом Linux. Увы, ссылка на OpenSUSE на сайте загрузки MonoDevelop оказалась нерабочей, а при попытке установить его на SLED возникла странная неразрешенная зависимость (из-за Glibc, ни больше ни меньше!). Итак, я отобрал четыре фанта у Novell и отправился на сайт (http://badgerports.org), где сидят последние версии пакетов Mono для Ubuntu 10.04, и они прекрасно установились. Для вашего сведения, я воспользовался Mono 2.6.7 и MonoDevelop 2.4.

Среды времени выполнения

(thumbnail)
Рис. 1. Найдите отличие! Простое приложение .NET Winforms, запущенное в Windows (слева) и в Linux (справа).

Я решил начать с малого и убедиться, что в Linux запускается простое приложение Windows Forms, скомпилированное в Windows. Эта маленькая программа – мой эквивалент «Hello World» для Winforms. Нужно было просто скопировать сборку .NET (EXE-файл) из Windows в Linux и запустить его в Mono. Она запустилась успешно, как показано на рисунке (см. рис. 1). Проясним происходящее: это не просто совместимость на уровне исходного кода – я взял приложение, скомпилированное в Windows, и запускаю его в Linux.

Работает ли это для более сложных приложений? Этот вопрос сводится к следующему: «Сколько классов среды .NET от Microsoft корректно реализованы в Mono?» Оцените масштаб: в библиотеке классов среды .NET (как мне говорили) около 11 000 классов. А поскольку в большинстве из этих классов по 20 или более методов и свойств, это очень много.

На сайте проекта Mono, http://www.mono-project.com/Compatibility, подробно представлены возможности .NET, реализованные и не реализованные в Mono. Итог, приведенный на этой странице, гласит: «Простейший способ описать все, что на данный момент поддерживает Mono, таков: все в .NET 4.0, кроме WPF, EntityFramework и WF; ограниченная поддержка WCF». Особо отметим, что поддержка Windows Presentation Foundation (WPF) не планируется. Гораздо более подробная информация приведена на Mono Class Status Pages, сайт http://go-mono.com/status. Здесь в браузере объектов мы можем продвигаться от пространств имен .NET к классам, методам и свойствам и видеть, что именно реализовано в Mono и что нет. Я заглянул в пространство имен System.Drawing (экранный снимок на рис. 2 внизу) и обнаружил, что многие классы, такие как Bitmap, Brush и Graphics (выделены зеленым), полностью реализованы, но у класса BufferedGraphics есть метод (Render) с одним перегруженным вариантом, который нельзя реализовать в библиотеке libgdiplus.

Группа поддержки

Вооруженный этой информацией (и с учетом того, что на снимке показано лишь около 10 % одного из более чем 50 пространств имен) разработчик в принципе мог бы просмотреть свой код и понять, есть ли в нем что-то неподдерживаемое Mono. Если вы считаете, что это тупая задача, которую обязан делать компьютер, вы правы! В самом деле, утилита Moma (Mono Migration Analyzer) сделает это за вас. На входе Moma принимает набор сборок (файлов EXE и DLL), образующих приложение, проверяет их и сообщает, есть ли в них нереализованные функции.

Если Moma дает приложению «зеленый свет», это не гарантия его корректного запуска в Linux. У разработчика много способов определить по коду, на какой платформе он должен запускаться. Например, программа может искать внешние файлы в каталогах Windows или предполагать, что запущен локальный сервер IIS. Moma, безусловно, удобное средство для выявления проблемных областей, и это, конечно, приложение .NET.

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

Запуск программ Mono

В отличие от скомпилированных исходников или скриптов оболочки, программы .NET нельзя запускать, указывая только имя программы в качестве команды. Программу должен явно загрузить Mono, по команде

$ mono mydotnetapp.exe

Простое решение этой проблемы – создать маленькую обертку в виде скрипта оболочки вокруг каждого приложения .NET. Вот как это делается для утилит в дистрибутиве Mono. Пусть утилита gacutil находится в файле /usr/lib/mono/2.0/gacutil.exe, а ее скрипт оболочки – в /usr/bin/gacutil; в нем всего одна строка:

exec /usr/bin/mono $MONO_OPTIONS /usr/lib/mono/2.0/gacutil.exe “$@”

Учтите, что binfmt, модуль ядра Linux, позволяет регистрировать форматы исполняемых файлов, распознавать их и передавать приложениям пользователей.

Среды разработки

Теперь перейдем к сравнению сред разработки. Здесь менее понятно, что с чем сравнить. Microsoft предлагает набор средств разработки с постоянно расширяющимися возможностями (по постоянно растущим ценам), от Visual C# Express (бесплатного) до Visual Studio Professional, Premium и Ultimate. Наверное, лучше всего сравнивать с Express – все остальное только подчеркнет разницу.

Основное средство разработки в Mono – MonoDevelop. С MonoDevelop я столкнулся впервые и был приятно удивлен, увидев безупречную среду разработки с полным набором функций. В ней есть разворачиваемый текстовый редактор с подцветкой синтаксиса и обширной контекстной справкой, подобной IntelliSense от Microsoft. Имеются шаблоны кода (Microsoft называет их «snippets») – например, пустой цикл for, вставляемый в код парой щелчков мыши. Есть и встроенный отладчик – в нем можно использовать точки останова по условию, как в Visual Studio. Аналогичен и редактор свойств. Хотя между этими редакторами встречаются значительные различия, переход с Visual Studio на MonoDevelop, по-моему, должен пройти достаточно безболезненно.

Я попытался создать простую форму и был ошеломлен тем, что она основана на инструментарии GTK. Я ожидал увидеть архитектуру и набор панелей инструментов, аналогичные Windows Forms. Оглядываясь назад, скажу: это предположение было наивным – но помните, что я переходил на эту среду, привыкнув к Visual Studio/Winforms. Структура форм в GTK значительно отличается: гораздо большая роль уделяется «компонентам-контейнерам», определяющим раскладку, тогда как в Windows компоненты обычно размещаются по своим абсолютным координатам. (Подробнее об этом см. на http://www.mono-project.com/GtkSharp:_Widget_Layout_and_Packing).

Вообще-то существует конструктор форм Winforms для Mono (см. http://www.mono-project.com/WinForms_Designer), под названием mwf-designer. Я загрузил его и немного с ним поработал, но скоро согласился с комментарием на его домашней странице: «конструктор еще не готов для полноценной работы». Простую форму создать можно, но масса возможностей еще не реализована. Также нет встроенной возможности сборки/запуска/отладки, и код формы нужно сохранять в файл, а затем компилировать с командной строки (или, скорее, загрузить в конструктор Visual Studio – но я этого не пробовал). Звездный час этого конструктора, безусловно, еще впереди.

В Mono также есть набор утилит командной строки, похожих на предлагаемые Microsoft SDK. Есть, например, gacutil, утилита для работы с глобальным кэшем сборок (Global Assembly Cache – GAC), где находятся все разделяемые сборки. Также есть wsdl (утилита для написания прокси web-сервисов) и monodies (утилита для «разборки» сборок и просмотра их содержимого на промежуточном языке), с функциональностью, подобной ildasm от Microsoft.

Mono в мейнстриме

На разработку Mono явно потратила кучу времени целая когорта умников. Согласно сайту проекта, Mono запускается в Android, BSD, iOS, Linux, Mac OS X, Windows, Solaris и Unix, а также в ОС ряда игровых консолей, например, PlayStation 3, Wii и Xbox 360. Сам я проверил только Linux. Обещание «пиши один раз, запускай везде» очень раздразнивает аппетит, но Mono всегда будет играть в догонялки с Microsoft, которая продолжает рационализировать и вводить новые технологии в .NET, и трудно сказать, будут ли производители ПО ориентировать свои продукты на запуск в любой ОС с поддержкой .NET.

Пожалуй, еще рано оценивать значение .NET как независимой от платформы среды и Mono как ее полной реализации. Время покажет.

Персональные инструменты
купить
подписаться
Яндекс.Метрика