Чи готовий Mono до прайм-тайму? [зачинено]

Хто-небудь використовував Mono, реалізацію з відкритим кодом .NET у великому чи середньому проекті? Мені цікаво, чи готовий він до реального світу, виробничого середовища. Чи стабільний, швидкий, сумісний, ... достатній для використання? Потрібно чимало зусиль, щоб перенести проекти на виконання Mono, або це насправді, насправді досить сумісні , щоб просто взяти і запустити з уже написаного коду для виконання від Microsoft?

Існує кілька сценаріїв, які слід врахувати: (а) якщо ви переносите наявну програму і цікавитеся, чи Mono достатньо хороший для цього завдання; (b) ви починаєте писати якийсь новий код, і хочете дізнатися, чи достатньо зріла 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-сервер або інші популярні бази даних (є багато постачальників баз даних з Mono).

Перенос файлів Windows.Forms іноді складніший, оскільки розробники люблять уникнути. Або якийсь такий мотлох.

Він має досить широке охоплення до .NET 4.0 і навіть включає деякі функції API .NET 4.5, але є кілька областей, які ми вирішили не застосовувати через застарілі API, створення нових альтернатив або надто масштабність великий. Наступні API не доступні в Mono:

• Фонд презентацій Windows
• Фонд робочого процесу Windows (жодна з двох версій)
• Entity Framework
• "Додатки" WSE1 / WSE2 до стандартного стеку веб-служб

Крім того, наша реалізація WCF обмежена тим, що підтримував Silverlight.

Найпростіший спосіб перевірити свій конкретний проект - це запустити аналізатор моногранічності (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, або робити це самостійно, якщо у вас є доступ до оболонки до вашого хоста.

Так чи інакше, Моно чудовий і стабільний.

Ключові речі, які слід пам’ятати, створюючи кросплатформну програму:

• Використовуйте GTK # замість Windows.Forms
• Переконайтесь, що ви правильно зареєстрували свої імена файлів
• Використовуйте Path.Separatorзамість жорсткого кодування "\", також використовуйте Environment.NewLineзамість "\n".
• Не використовуйте P / Invoked дзвінки до Win32 API.
• Не використовуйте Реєстр Windows.

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

Є особливості, і одна з найприємніших речей полягає в тому, що ви не можете просто "скласти" файли msbuild через поточний стан Mono:

• MonoDevelop (IDE) має деяку часткову підтримку msbuild, але в основному буде працювати на будь-якій "РЕАЛЬНІЙ" конфігурації побудови поза простим привітним світом (спеціальні завдання побудови, динамічні "властивості", як $ (SolutionDir), реальна конфігурація для назви кількох мертвих -закінчується)
• xbuild, який ДОЛЖЕН би бути моно-постачаною-msbuild-повністю сумісною-build-системою, ще жахливіший, тому побудова з командного рядка насправді є гіршим досвідом, ніж використання графічного інтерфейсу, що є дуже "неортодоксальним" станом об'єднання для середовищ Linux ...

Після того, як / під час отримання ваших речей НАЗАВИДЕНО, ви можете побачити деякі пустелі навіть для коду, який ДОЛЖЕН підтримувати, наприклад:

• компілятор стає borked на певних конструкціях
• і деякі більш просунуті / нові .NET-класи кладуть на вас несподіване лайно (хтось XLinq?)
• деякі "незрілі" функції "(обмеження на 3 ГБ на ВКЛ x64 ... WTF!)

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

Після того, як ви перейшли ці початкові перешкоди, мій досвід полягає в тому, що моно ROCKS, і все краще покращується з кожною ітерацією .

У мене були сервери, які працюють з моно, обробляючи 300 ГБ даних на день, з тоннами p / викликів і взагалі кажучи, РОБОТИ багато роботи і залишатися вгору протягом 5-6 місяців, навіть з моно "кровоточим краєм".

Сподіваюсь, це допомагає.

Рекомендації щодо прийнятої відповіді зараз трохи застаріли.

• Зараз впровадження форм Windows досить добре. (Див. Paint-Mono для порту Paint.net, який є досить задіяним додатком для форм Windows. Все, що було потрібно, - шар емуляції для деяких системних дзвінків P-Invoke та непідтримуваних).
• Path.Combine, а також Path.Seperator для об'єднання шляхів та імен файлів.
• Реєстр Windows нормально, якщо ви використовуєте його лише для зберігання та отримання даних зі своїх додатків (тобто ви не можете отримати з нього жодної інформації про Windows, оскільки це в основному реєстр програм Mono).

Якщо ви хочете використовувати WPF, вам не сподобається, Mono наразі не планує його реалізовувати.

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

Ну, моно - це чудово, але наскільки я бачу, він нестабільний. Це працює, але несправності, коли ви даєте монопроцесу серйозну роботу.

TL; DR - Не використовуйте моно, якщо:

• використовувати AppDomains (Assembly Load \ Unload) у багатопотокових середовищах
• Не вдається витримати модель "нехай-провалить"
• Досвід випадкових важких навантажень під час виконання процесу

Отже, факти.

Ми використовуємо моно-2.6.7 (.net v 3.5) для RHEL5, Ubuntu, і, на мій погляд, це найбільш стабільна версія, побудована Novell. У нього є проблема з вивантаженням 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 segfaults обробляють майже негайно
• моно з боем живе довше (від 2 до 5 годин), але врешті-решт segfault

Як згадувалося вище, sgen gc просто не працює (монобудований з джерела):

* 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 segfauls - наприклад (Ubuntu 13.04, побудований з джерела):

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, моно знімається з 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, тому вам слід триматися подалі від них в моно.

BTW, перевірена програма працювала 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 код (наприклад, код доступу до реєстру). Але я думаю, що найгіршим правопорушником є ​​код UI. Це особливо погано в системах Macintosh.

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

Єдине велике питання, про яке я можу подумати, сталося близько місяця тому. У збірці Linux виникла пам'ять, якої не було помічено в збірці Windows. Зробивши вручну налагодження (основні анкети Mono на Linux не дуже допомогли), ми змогли звузити проблему до конкретного фрагмента коду. Ми закінчили виправлення вирішення проблеми, але мені ще потрібно знайти якийсь час, щоб повернутися назад і зрозуміти, в чому полягала першопричина витоку.

Чи знаєте ви, наскільки хороша підтримка попереднього перегляду Mono 2.0 для Windows Forms 2.0?

З того небагато, що я грав із цим, він здавався відносно повним і майже корисним. Це просто не зовсім добре виглядало в деяких місцях і все ще є невеликим ударом або загалом пропущено. Мене вразило, що це спрацювало так само добре, як це було зроблено з деякими нашими формами, хоча і чесно.

Так, це безумовно (якщо ви обережні). Ми підтримуємо Mono в Ра-Аяксі (бібліотека Ajax, знайдена на веб-сайті http://ra-ajax.org ), і у нас в основному не виникає проблем. Вам потрібно бути обережними з деякими "найсумнішими речами" від .Net, як WSE тощо, а також, мабуть, досить багато ваших існуючих проектів не будуть на 100% сумісними моно, але нові проекти, якщо ви протестуєте їх під час розробки, в основному бути сумісним без проблем з 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, і використовували значно більше пам'яті. Тримайтеся подалі від моно для серйозної роботи.