Кто-нибудь использовал Mono, реализацию с открытым исходным кодом .NET для крупного или среднего проекта? Мне интересно, готова ли она для реального мира, производственных сред. Это стабильно, быстро, совместимо, ... достаточно для использования? Требуется ли много усилий для переноса проектов в среду выполнения Mono, или это действительно достаточно совместимо, чтобы просто взять и запустить уже написанный код для среды выполнения Microsoft?
.net
open-source
mono
wvdschel
источник
источник
Ответы:
Есть несколько сценариев, которые следует учитывать: (а) если вы переносите существующее приложение и задаетесь вопросом, достаточно ли Mono для этой задачи; (б) вы начинаете писать новый код и хотите знать, достаточно ли зрел 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. Или что-то вроде барахла.
источник
Он имеет довольно обширный охват вплоть до .NET 4.0 и даже включает некоторые функции API-интерфейсов .NET 4.5, но есть несколько областей, которые мы решили не реализовывать из-за устаревших API, новых альтернатив или создания области действия. большой. Следующие API не доступны в Mono:
Кроме того, наша реализация WCF ограничена тем, что поддерживается Silverlight.
Самый простой способ проверить ваш конкретный проект - запустить Mono Migration Analyzer (MoMA) . Преимущество заключается в том, что он уведомит команду Mono о проблемах, которые не позволят вам использовать Mono (если таковые имеются), что позволит им расставить приоритеты в своей работе.
Недавно я запустил MoMA на SubSonic и обнаружил только одну проблему - странное использование типов Nullable. Это большая кодовая база, поэтому охват там был довольно впечатляющим.
Mono активно используется в нескольких коммерческих и открытых продуктах . Он используется в некоторых крупных приложениях, таких как Википедия и Центр разработчиков Mozilla , и использовался во встроенных приложениях, таких как MP3-плееры Sansa, и поддерживает тысячи опубликованных игр.
На уровне языка компилятор Mono полностью соответствует спецификации языка C # 5.0 .
источник
На настольном ПК Mono отлично работает, если вы берете на себя обязательство использовать GTK #. Реализация Windows.Forms все еще немного глючит (например, TrayIcon не работает), но она прошла долгий путь. Кроме того, GTK # лучше, чем Windows Forms.
На веб-сайте Mono реализовал достаточно ASP.NET для идеального запуска большинства сайтов. Сложность здесь заключается в том, чтобы найти хост с установленным mod_mono на apache или сделать это самостоятельно, если у вас есть доступ к вашему хосту через оболочку.
В любом случае, Mono великолепен и стабилен.
Основные моменты, которые следует помнить при создании кроссплатформенной программы:
Path.Separator
вместо жесткого кодирования"\"
, также используйтеEnvironment.NewLine
вместо"\n"
.источник
Я лично использую Mono в прайм-тайм env. Я использую моно-серверы, занимающиеся гигабайтами задач, связанных с обработкой данных udp / tcp, и не могу быть счастливее.
Есть некоторые особенности, и одна из самых раздражающих вещей заключается в том, что вы не можете просто «собрать» ваши файлы msbuild из-за текущего состояния Mono:
Однажды / во время получения ваших вещей фактически СОЗДАННЫХ, вы можете увидеть некоторые проблемы даже для кода, который СЛЕДУЕТ поддерживать, например:
но он сказал, что, вообще говоря, вещи начинают работать очень быстро, и решения / обходные пути имеются в изобилии .
После того, как вы преодолели эти начальные препятствия, мой опыт показывает, что моно ROCKS постоянно улучшается с каждой итерацией .
У меня были серверы, работающие с моно, обрабатывающие 300 ГБ данных в день, с тоннами вызовов p / и, вообще говоря, выполняющими МНОГО работы и работающими в течение 5-6 месяцев, даже с монофоническим «острым краем».
Надеюсь это поможет.
источник
Рекомендации для принятого ответа сейчас немного устарели.
источник
Если вы хотите использовать WPF, вам не повезло: Mono в настоящее время не планирует его внедрять.
http://www.mono-project.com/WPF
источник
Ну, моно это здорово, но насколько я вижу, оно нестабильно. Это работает, но дает сбой, когда вы даете моно процессу серьезную работу.
TL; DR - не используйте моно, если вы:
Итак, факты.
Мы используем mono-2.6.7 (.net v 3.5) на RHEL5, Ubuntu, и, на мой взгляд, это самая стабильная версия, созданная Novell. У него есть проблема с Unloading AppDomains (segfaults), однако, это происходит очень редко, и это, безусловно, приемлемо (для нас).
Ладно. Но если вы хотите использовать функции .net 4.0, вам нужно переключиться на версии 2.10.x или 3.x, и вот тут начинаются проблемы.
По сравнению с 2.6.7 новые версии просто недопустимы. Я написал простое приложение для стресс-теста для тестирования моно установок.
Это здесь, с инструкциями по использованию: https://github.com/head-thrash/stress_test_mono
Он использует рабочие потоки пула потоков. Работник загружает DLL в AppDomain и пытается выполнить некоторую математическую работу. Некоторые работы многопоточные, некоторые одиночные. Почти вся работа связана с процессором, хотя есть некоторые операции чтения файлов с диска.
Результаты не очень хорошие. Фактически для версии 3.0.12:
Как уже упоминалось выше, sgen gc просто не работает (моно собран из исходного кода):
Что касается Boehm Segfauls - например (Ubuntu 13.04, моно построен из источника):
Или (RHEL5, моно взят из rpm здесь ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )
Оба сбоя так или иначе связаны с логикой AppDomains, поэтому вы должны держаться подальше от них в моно.
Кстати, протестированная программа работала 24 часа на Windows-машине в MS .NET 4.5 env без сбоев.
Итак, в заключение я бы хотел сказать - используйте моно с осторожностью. Это работает с первого взгляда, но может легко потерпеть неудачу всякий раз. Вы останетесь с кучей основных дампов и большой потерей веры в проекты с открытым исходным кодом.
источник
MoMA является отличным инструментом для этого, как кто-то предложил. Крупнейшими источниками несовместимости в наши дни являются приложения, которые DllImport (или P / Invoke) в библиотеки Win32. Некоторые сборки не реализованы, но большинство из них предназначены только для Windows и не имеют смысла в Linux. Я думаю, можно с уверенностью сказать, что большинство приложений ASP.NET могут работать на Mono с ограниченными модификациями.
(Раскрытие: я внес свой вклад в сам Mono, а также в написанные приложения, которые работают поверх него.)
источник
Во многих случаях вы можете взять существующий код и просто запустить его в Mono, особенно если вы переносите приложение ASP.NET.
В некоторых случаях вам может потребоваться новые разделы кода, чтобы он работал. Например, если вы используете System.Windows.Forms, приложение не будет работать без изменений. Аналогично, если вы используете какой-либо специфичный для Windows код (например, код доступа к реестру). Но я думаю, что худшим нарушителем является код пользовательского интерфейса. Это особенно плохо в системах Macintosh.
источник
Мы использовали его для работающего здесь проекта, который должен был работать в Linux, но повторно использовать некоторые библиотеки .NET, которые мы создали в Managed C ++. Я был очень удивлен тем, насколько хорошо это сработало. Наш основной исполняемый файл написан на C #, и мы можем без проблем ссылаться на наши управляемые двоичные файлы C ++. Единственная разница в коде C # между Windows и Linux - это код последовательного порта RS232.
Единственная большая проблема, о которой я могу думать, произошла около месяца назад. В сборке Linux произошла утечка памяти, которой не было в сборке Windows. После некоторой ручной отладки (основные профилировщики для Mono в Linux не сильно помогли), мы смогли сузить проблему до определенного фрагмента кода. Мы закончили исправление обходного пути, но мне все еще нужно найти время, чтобы вернуться и выяснить, какова была основная причина утечки.
источник
Судя по тому, что я играл с ним, он казался относительно полным и почти пригодным для использования. В некоторых местах он выглядит не совсем корректно, и в целом он все еще немного поражает. Меня поразило, что это работает так же хорошо, как и с некоторыми из наших форм, хотя и честно.
источник
Да, это определенно (если вы осторожны). Мы поддерживаем Mono в Ra-Ajax (библиотека Ajax, найденная на http://ra-ajax.org ), и у нас в основном вообще нет проблем. Вы должны быть осторожны с некоторыми «самыми безумными вещами» из .Net, такими как WSE и т. Д., А также, вероятно, некоторые из ваших существующих проектов не будут на 100% совместимы с Mono, но новые проекты, если вы их протестируете во время разработки, в основном будут быть совместимым без проблем с Mono. И выгода от поддержки Linux и т. Д. Благодаря использованию Mono - это действительно здорово;)
Большая часть секрета поддержки Mono, я думаю, заключается в том, чтобы с самого начала использовать правильные инструменты, например ActiveRecord, log4net, ra-ajax и т. Д.
источник
Для типа приложения, которое мы создаем, к сожалению, 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. Все (клиент, сервер, графический интерфейс, инструменты слияния) написано на моно.
источник
Это действительно зависит от пространств имен и классов, которые вы используете из .NET Framework. Я был заинтересован в преобразовании одной из моих служб Windows для работы на моем почтовом сервере, которой является Suse, но мы столкнулись с несколькими серьезными препятствиями с API, которые не были полностью реализованы. Где-то на веб-сайте Mono есть таблица, в которой перечислены все классы и уровень их завершения. Если ваша заявка покрыта, то пойти на это.
Как и в любом другом приложении, выполняйте прототипирование и тестирование, прежде чем полностью взять на себя обязательство, конечно.
Еще одна проблема, с которой мы столкнулись, - это лицензионное программное обеспечение: если вы ссылаетесь на чужую DLL, вы не можете закодировать свой путь несовместимости, скрытой в этой сборке.
источник
Тогда я представляю, что если у вас есть приложение с какими-то сторонними компонентами, вы можете его заполнить. Я сомневаюсь, что многие поставщики будут развиваться с учетом Mono
Пример: http://community.devexpress.com/forums/p/55085/185853.aspx
источник
Нет, моно не готов к серьезной работе. Я написал несколько программ для Windows с использованием F # и запустил их на Mono. Эти программы довольно интенсивно использовали диск, память и процессор. Я видел сбои в моно библиотеках (управляемый код), сбои в нативном коде и сбои на виртуальной машине. Когда моно работал, программы были как минимум в два раза медленнее, чем в .Net в Windows, и использовали гораздо больше памяти. Держитесь подальше от моно для серьезной работы.
источник