Моно готов к прайм-тайму

.net open-source mono


Кто-нибудь использовал Mono, реализацию .NET с открытым исходным кодом в большом или среднем проекте? Мне интересно, готов ли он к реальному миру, производственной среде. Он стабильный, быстрый, совместимый, ... достаточно ли он для использования? Требуется ли много усилий для переноса проектов в среду выполнения Mono, или она действительно достаточно совместима, чтобы просто взять и запустить уже написанный код для среды выполнения Microsoft?




Answer 1 miguel.de.icaza


Есть пара сценариев для рассмотрения:(a)если вы портируете существующее приложение и задаетесь вопросом,достаточно ли хорош Mono для этой задачи;(b)вы начинаете писать новый код,и вы хотите знать,достаточно ли созрел Mono.

В первом случае вы можете использовать инструмент Mono Migration Analyzer (Moma), чтобы оценить, насколько далеко ваше приложение от запуска на Mono. Если оценка вернется с честью, вам следует начать тестирование и контроль качества и приготовиться к отправке.

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

Согласно нашей статистике Moma,основанной на данных,предоставленных пользователями (это из памяти),около 50% приложений работают "из коробки",около 25% требуют около недели работы (рефакторинг,адаптация),еще 15% требуют серьезного обязательства переделать куски вашего кода,а остальное просто не стоит беспокоиться о портировании,так как они так невероятно привязаны к Win32.В этот момент либо вы начинаете с нуля,либо бизнес-решение будет стимулировать усилия,чтобы сделать ваш код портативным,но мы говорим месяцы работы (по крайней мере,из отчетов,которые у нас есть).

Если вы начинаете с нуля,ситуация намного проще,потому что вы будете использовать только те API,которые присутствуют в Mono.До тех пор,пока вы останетесь с поддерживаемым стеком (который представляет собой практически .NET 2.0,плюс все основные обновления в 3.5,включая LINQ и System.Core,плюс любой из кросс-платформенных API Mono),вы будете в порядке.

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

Что касается портативности:ASP.NET-приложения проще портировать,так как они практически не зависят от Win32,и вы даже можете использовать SQL-сервер или другие популярные базы данных (существует множество провайдеров баз данных в комплекте с Mono).

Перенос Windows.Forms иногда бывает сложнее,потому что разработчикам нравится избегать .NET песочницы и P/Invoke их мозги,чтобы настроить такие вещи,как изменение скорости мигания курсора,выраженное в виде двух точек безье,закодированных в BCD форме в wParam.Или какой-нибудь хлам вроде этого.




Answer 2 Jon Galloway


Он имеет довольно обширное покрытие до .NET 4.0 и даже включает некоторые функции из .NET 4.5 API,но есть несколько областей,которые мы решили не реализовывать из-за того,что API устаревают,создаются новые альтернативы или область применения слишком велика.Следующие API недоступны в Моно:

  • Фонд Windows Presentation Foundation
  • Windows Workflow Foundation (ни одна из двух версий)
  • Структурная структура
  • Дополнительные модули WSE1/WSE2 к стандартному стеку Web Services pack

Кроме того,наше внедрение WCF ограничивается тем,что поддерживается Silverlight.

Самый простой способ проверить свой конкретный проект - запустить Mono Migration Analyzer (MoMA) . Преимущество состоит в том, что он уведомит команду Mono о проблемах, которые не позволят вам использовать Mono (если таковые имеются), что позволяет им расставить приоритеты в своей работе.

Недавно я запустил MoMA на SubSonic и нашел только одну проблему-странное использование типов Nullable.Это большая кодовая база,так что освещение там было довольно впечатляющим.

Mono активно используется в нескольких коммерческих продуктах, а также в продуктах с открытым исходным кодом . Он используется в некоторых крупных приложениях, таких как Википедия и Центр разработчиков Mozilla , а также во встроенных приложениях, таких как MP3-плееры Sansa, и поддерживает тысячи опубликованных игр.

На уровне языка компилятор Mono полностью соответствует спецификации языка C # 5.0 .




Answer 3 FlySwat


Со стороны рабочего стола,Mono отлично работает,если вы берете на себя обязательство использовать GTK#.Реализация Windows.Forms все еще немного багична (например,TrayIcon не работает),но она прошла долгий путь.Кроме того,GTK#и так является лучшим инструментарием,чем Windows Forms.

На веб-странице,Mono внедрила достаточно ASP.NET для отличной работы большинства сайтов.Сложность здесь заключается в том,чтобы найти хост,на котором установлен mod_mono на apache,или сделать это самостоятельно,если у вас есть доступ к вашему хосту через оболочку командной строки.

В любом случае,Моно великолепен и стабилен.

Ключевые вещи,которые следует помнить при создании кроссплатформенной программы:

  • Используйте GTK#вместо Windows.Forms.
  • Убедитесь,что ваши имена
  • Используйте Path.Separator вместо жесткого кодирования "\" , также используйте Environment.NewLine вместо "\n" .
  • Не используйте P/Invoked вызовы к Win32 API.
  • Не используйте реестр Windows.



Answer 4 damageboy


Я лично использую Моно в прайм-тайм зависти.Я запускаю моносерверы,работающие с гигабайтами задач,связанных с обработкой данных udp/tcp,и это не может не радовать.

Есть особенности,и одна из самых раздражающих вещей заключается в том,что Вы не можете просто "построить" свои msbuild файлы из-за текущего состояния Моно:

  • MonoDevelop (IDE)имеет частичную поддержку msbuild,но в основном будет работать с любой "REAL" сборкой,выходя за рамки простого Hello-world (пользовательские задачи сборки,динамические "свойства" типа $(SolutionDir),реальная конфигурация,чтобы назвать несколько тупиковых моментов).
  • xbuild, который ДОЛЖЕН быть моно-поставленной-msbuild-полностью-совместимой-системой сборки, еще более ужасен, поэтому сборка из командной строки на самом деле хуже, чем использование графического интерфейса, что является очень "неортодоксальным" состоянием union для сред Linux ...

Однажды/During получив свой материал на самом деле BUILT,вы можете увидеть некоторые пустынные места даже для кода,который ДОЛЖЕН поддерживаться как:

  • компилятору приходится работать с определенными конструкциями.
  • и некоторые более продвинутые/новые .NET классы,бросающие в вас нежданное дерьмо (XLinq кто-нибудь?).
  • некоторые незрелые "особенности" выполнения (лимит кучи 3 Гб ВКЛ x64...WTF!)

но он сказал, что в целом все начинает работать очень быстро, и решений / обходных путей предостаточно .

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

У меня были серверы,работающие с моно,обрабатывающие 300 ГБ данных в день,с тоннами p/invokes и вообще делающие LOTS работы и оставаясь UP в течение 5-6 месяцев,даже с "кровоточащим краем" моно.

Надеюсь,это поможет.




Answer 5 Kris Erickson


Рекомендации в отношении принятого ответа сейчас немного устарели.

  • Реализация оконных форм сейчас довольно хороша. (См. Paint-Mono для порта Paint.net, который представляет собой довольно сложное приложение для работы с формами Windows. Все, что требовалось, - это слой эмуляции для некоторых из P-Invoke и неподдерживаемых системных вызовов).
  • Path.Combine,а также Path.Seperator для соединения путей и имен файлов.
  • Реестр windows-это нормально,если вы используете его только для хранения и извлечения данных из приложений (т.е.вы не можете получить из него никакой информации о Windows,поскольку по сути это реестр для приложений Mono).