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

https://stackoverflow.com/questions/18450

09-06-2019
|

Вопрос

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

Решение

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

В первом случае вы можете использовать Инструмент Анализа миграции Mono (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 server или другие популярные базы данных (существует множество поставщиков баз данных в комплекте с Mono).

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

Другие советы

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

Основа для создания презентаций Windows
Windows Workflow Foundation (ни одна из двух версий)
Структура сущностей
"Дополнения" WSE1 / WSE2 к стандартному стеку веб-служб

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

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

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

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

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

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

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

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

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

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

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

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

MonoDevelop (IDE) имеет некоторую частичную поддержку msbuild, но в основном будет работать с любым "РЕАЛЬНЫМ" build conf, выходящим за рамки простого hello-world (пользовательские задачи сборки, динамические "свойства", такие как $ (SolutionDir), реальная конфигурация, чтобы назвать несколько тупиков)
xbuild, который ДОЛЖНО было быть монокомпонентная msbuild-fully-compatible-build-system является еще более ужасной, поэтому сборка из командной строки на самом деле является худшим опытом, чем использование графического интерфейса пользователя, который является очень "неортодоксальным" состоянием союза для сред Linux...

После / Во время создания вашего материала вы можете увидеть некоторые пробелы даже для кода, который ДОЛЖЕН поддерживаться следующим образом:

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

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

Как только вы преодолеете эти начальные препятствия, мой опыт покажет, что mono РАБОТАЕТ отлично и становится лучше с каждой итерацией.

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

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

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

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

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

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

Что ж, моно - это здорово, но, насколько я могу судить, оно нестабильно.Это работает, но дает сбои, когда вы поручаете mono process серьезную работу.

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

используйте AppDomains (загрузка \ выгрузка сборки) в многопоточных средах
Не могу поддерживать модель "пусть все провалится"
Время от времени возникают события с большой нагрузкой во время выполнения процесса

Итак, факты.

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

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

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

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

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

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

сегменты sgen GC обрабатываются практически мгновенно
моно с boehm живет дольше (от 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]

Что касается сегментов boehm - например (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.

Кстати, протестированная программа проработала 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 код (например, код доступа к реестру).Но я думаю, что худшим нарушителем является код пользовательского интерфейса.Это особенно плохо в системах Macintosh.

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

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

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

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

Да, это определенно так (если вы будете осторожны) Мы поддерживаем 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 это работало, но как только мы переходили к большему набору данных, он тоже выходил из строя.

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow