Готов ли Mono к прайм-тайму?

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

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

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

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

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

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

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

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

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

• Windows Презентация Фонда
• Windows Workflow Foundation (ни одна из двух версий)
• платформа Entity Framework
• WSE1/WSE2 "add-ons" к стандартному стеку веб-служб

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

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

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

Mono активно используется в нескольких коммерческих и открытых продуктах . Он используется в некоторых крупных приложениях , таких как Wikipedia и Mozilla Developer Center, а также используется во встроенных приложениях, таких как Sansa MP3 players и powers тысяч опубликованных игр.

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

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

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

В любом случае, Mono-это здорово и стабильно.

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

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

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

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

• MonoDevelop (the IDE) имеет некоторую частичную поддержку msbuild, но в основном будет Борк на любом "REAL" build conf за пределами простого hello-world (пользовательские задачи сборки, динамические "properties", такие как $(SolutionDir), реальная конфигурация, чтобы назвать несколько тупиков)
• xbuild, который SHOULD был mono-supplied-msbuild-fully-compatible-build-system, еще более ужасен, поэтому построение из командной строки на самом деле является худшим опытом, чем использование GUI, который является очень "unorthodox" состоянием союза для Linux сред...

Как только / во время получения вашего материала на самом деле BUILT, вы можете увидеть некоторые дикости даже для кода, который SHOULD поддерживается, как:

• компилятор становится скучным на определенных конструкциях
• и некоторые более продвинутые / новые классы .NET бросают в вас неожиданное дерьмо (XLinq кто-нибудь?)
• некоторые незрелые runtime "features" (3GB heap limit ON x64... WTF!)

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

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

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

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

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

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

Если вы хотите использовать WPF, вам не повезло Mono в настоящее время не планирует его реализовывать.

http://www.mono-project.com/WPF

Ну, 54-й-это здорово, но, насколько я вижу, он нестабилен. Он работает, но ошибается, когда вы даете mono процессу серьезную работу.

TL;DR - не используйте mono, если вы :

• используйте AppDomains (Assembly Load\Unload) в многопоточных средах
• Не могу сохранить let-it-fail модели
• Испытайте случайные события большой нагрузки во время выполнения процесса

Итак, факты.

Мы используем mono-2.6.7 (.net v 3.5) на RHEL5, Ubuntu, и, на мой взгляд, это самая стабильная версия, построенная Novell. У него есть проблема с разгрузкой AppDomains (segfaults), однако он очень редко выходит из строя, и это, безусловно, приемлемо (для нас).

Окей. Но если вы хотите использовать функции .net 4.0, вам нужно переключиться на версии 2.10.x или 3.x, и именно там начинаются проблемы.

По сравнению с 2.6.7, новые версии просто неприемлемы для использования. Я написал простое приложение для стресс-тестов для тестирования установок mono.

Это здесь, с инструкцией по использованию: https://github.com/head-thrash/stress_test_mono

Он использует рабочие потоки пула потоков. Рабочий загружает dll в AppDomain и пытается выполнить некоторую математическую работу. Некоторые работы многопоточны, некоторые единичны. Почти вся работа связана с CPU, хотя есть некоторые чтения файлов с диска.

Результаты не очень хорошие. На самом деле, для версии 3.0.12:

• sgen GC segfaults обрабатывается практически мгновенно
• mono с Бемом живет дольше (от 2 до 5 часов), но сегфаульты со временем исчезают

Как уже упоминалось выше, sgen gc просто не работает (mono построен из исходного кода):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

Что касается сегфаулов Бема - например (Ubuntu 13.04, mono построен из исходного кода):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

Или (RHEL5, mono берется из rpm здесь ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

Оба сбоя каким-то образом связаны с логикой AppDomains, поэтому вам следует держаться подальше от них в mono.

BTW, испытанная программа работала 24 часа на машине Windows в MS .NET 4.5 env без каких-либо сбоев.

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

MoMA-отличный инструмент для этого, как предположил кто-то другой. Самые большие источники несовместимости в наши дни-это приложения, которые DllImport (или P/Invoke)) входят в библиотеки Win32. Некоторые сборки не реализованы, но большинство из них являются Windows-только и действительно не имеют смысла на Linux. Я думаю, что вполне безопасно сказать, что большинство ASP.NET приложений может работать на Mono с ограниченными модификациями.

(Раскрытие: я внес свой вклад в саму Mono, а также написал приложения, которые работают поверх нее.)

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

В некоторых случаях вам могут потребоваться целые новые разделы кода, чтобы заставить его работать. Например, если вы используете System.Windows.Forms, приложение не будет работать в неизмененном виде. Аналогично, если вы используете любой Windows-специфичный код (например, код доступа к реестру). Но я думаю, что самый страшный преступник - это код UI. Это особенно плохо на системах Macintosh.

Мы использовали его для проекта здесь на работе, который должен был работать на Linux, но повторно использовать некоторые библиотеки .NET, которые мы построили в управляемом C++. Я был очень удивлен тем, как хорошо все получилось. Наш основной исполняемый файл пишется в C#, и мы можем просто ссылаться на наши управляемые двоичные файлы C++ без проблем. Единственное различие в коде C# между Windows и Linux - это код последовательного порта RS232.

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

Знаете ли вы, насколько хороша поддержка Mono 2.0 preview для Windows форм 2.0?

Из того немногого, что я играл с ним, он казался относительно полным и почти пригодным для использования. Это просто не совсем правильно выглядело в некоторых местах и все еще немного хит или промах в целом. Меня поразило, что он работал так же хорошо, как и с некоторыми из наших форм, хотя и честно.

Для типа приложения, которое мы создаем Mono, к сожалению, не кажется готовым к производству. Мы были впечатлены им в целом, и впечатлены его производительностью как на машинах Windows, так и на машинах EC2, однако наша программа разбилась последовательно с ошибками сборки мусора как на Windows, так и на linux.

Сообщение об ошибке: "фатальные ошибки в GC: слишком много разделов кучи", вот ссылка на кого-то другого, испытывающего проблему немного по-другому:

http://bugzilla.novell.com/show_bug.cgi?id=435906

Первый фрагмент кода, который мы запустили в Mono, был простой задачей программирования, которую мы разработали... Код загружает около 10 МБ данных в некоторые структуры данных (например, HashSets), а затем выполняет 10 запросов к данным. Мы пробежали запросы 100 раз, чтобы определить их время и получить среднее значение.

Код разбился около 55-го запроса на Windows. На linux это сработало, но как только мы перейдем к большему набору данных, он тоже рухнет.

Этот код очень прост, например: поместите некоторые данные в HashSets, а затем запросите эти HashSets и т. д., Все родные c#, ничего небезопасного, никаких вызовов API. На Microsoft CLR он никогда не падает, и работает на огромных наборах данных 1000 раз просто отлично.

Один из наших парней написал Мигелю по электронной почте и включил код, который вызвал проблему, но ответа пока не было. :(

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

Просто проверьте www.plasticscm.com. Все (клиент, сервер, GUI, инструменты слияния) написано на mono.

Да, это определенно так (если вы будете осторожны, хотя) Мы поддерживаем Mono в Ra-Ajax (Ajax библиотека найдена по адресу http://ra-ajax.org), и у нас в основном нет проблем вообще. Вы должны быть осторожны с некоторыми из "most insane things" от .Net, как WSE и т.д., а также, вероятно, довольно много ваших существующих проектов не будут совместимы с 100% Mono, но новые проекты, если вы протестируете их во время разработки, в основном будут совместимы без проблем с Mono. И выигрыш от поддержки Linux и т.д. через использование Mono действительно здорово ;)

Я думаю, что большая часть секрета поддержки Mono заключается в использовании правильных инструментов с самого начала, например ActiveRecord, log4net, ra-ajax и т. д...

Нет, mono не готов к серьезной работе. Я написал несколько программ на Windows, используя F#, и запустил их на Mono. Эти программы использовали диск, память и cpu довольно интенсивно. Я видел сбои в библиотеках mono (управляемый код), сбои в машинном коде и сбои в виртуальной машине. Когда mono работал, программы были по крайней мере в два раза медленнее, чем в .Net в Windows, и использовали гораздо больше памяти. Держитесь подальше от mono для серьезной работы.

Это действительно зависит от пространств имен и классов, которые вы используете из фреймворка .NET. У меня был интерес к преобразованию одного из моих сервисов windows для работы на моем сервере email, который является Suse, но мы столкнулись с несколькими жесткими препятствиями с APIs, которые не были полностью реализованы. Где-то на сайте Mono есть диаграмма, в которой перечислены все классы и их уровень завершения. Если ваша заявка покрыта, то идите на это.

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

Еще одна проблема, с которой мы столкнулись, - Это лицензионное программное обеспечение: если вы ссылаетесь на чей-то DLL, вы не можете кодировать свой путь вокруг несовместимостей, которые похоронены в этом assembly.

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

Пример: http://community.devexpress.com/forums/p/55085/185853.aspx