Mono готов к прайм-тайм? [закрыто]

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

20.08.2008 17:57:44
Mindtouch.com использует C # на Mono на Debian для очень надежной вики-платформы. Иди проверь их. Вы даже можете загрузить предварительно сконфигурированную виртуальную машину, которую вы можете легко настроить и использовать.
lamcro 17.11.2008 06:09:32
Я обнаружил, что наилучшее использование моно - это возможность сказать: «Если Microsoft сделает XXX, мы могли бы перейти на моно на Unix ...»
Ian Ringrose 7.02.2011 17:25:46
Я думаю, что этот вопрос заслуживает повторного рассмотрения, учитывая все, что изменилось после этого.
Jwosty 16.06.2014 23:28:22
17 ОТВЕТОВ
РЕШЕНИЕ

Есть несколько сценариев, которые следует учитывать: (а) если вы переносите существующее приложение и задаетесь вопросом, достаточно ли 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. Или что-то вроде барахла.

402
16.07.2009 14:59:09
Кем этот парень себя возомнил ? создатель моно ??? !! ... о, подождите ..
theman_on_vista 26.12.2008 17:32:00
@Drahcir: LINQ работает на Mono. Это не специфично для Windows. Так что давай и попробуй Linux.
Zifre 20.05.2009 23:34:59
«такие полезные вещи, как изменение частоты мигания курсора, выраженной в виде двух точек Безье, закодированных в виде BCD в wParam» lol
usr 25.10.2009 17:24:11
Большое спасибо за Моно ...
Evan Plaice 24.06.2010 01:23:31
Мигель, было бы неплохо получить обновление этого поста ;-)
David Schmitt 13.01.2012 08:33:46

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

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

4
20.08.2008 18:17:22

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

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

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

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

  • Используйте GTK # вместо Windows.Forms
  • Убедитесь в правильности ввода ваших имен файлов
  • Используйте Path.Separatorвместо жесткого кодирования "\", также используйте Environment.NewLineвместо "\n".
  • Не используйте вызовы P / Invoked для Win32 API.
  • Не используйте реестр Windows.
39
29.06.2011 12:33:39
Path.Separator - хороший совет, за исключением того, что Mono на OS X имеет ':', а не '/'! Ха! Это старый разделитель Mac OS (<= 9.0). Wha? Unix это / все пути.
Jared Updike 5.06.2010 07:29:06
Я не беспокоюсь о Environment.NewLine или Path.Separator, просто используйте / и \ n. Каждая настольная система, в настоящее время широко используемая (если я не пропускаю некоторые), использует / и \ n. Windows предпочитает \ и \ r \ n, но с радостью будет использовать Unix.
Programmdude 4.08.2013 13:29:22

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

  • Windows Presentation Foundation
  • Windows Workflow Foundation (ни одна из двух версий)
  • Entity Framework
  • Дополнения WSE1 / WSE2 к стандартному стеку веб-служб

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

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

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

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

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

65
21.04.2013 23:34:26

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

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

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

1
20.08.2008 18:21:50

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

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

2
20.08.2008 18:36:50

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

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

1
20.08.2008 18:38:48

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

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

4
20.08.2008 19:23:30
Итак, как вы пишете код для последовательных портов, который обрабатывает оба? Весь смысл CLR / Mono в том, чтобы быть независимым от платформы, верно? Это сделано в конфигурационных файлах?
Tim 12.01.2009 04:46:17

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

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

5
24.08.2008 02:12:54
Это Mono Migration Analyzer для тех, кто ломает голову и интересуется, как это связано с Музеем современного искусства.
Ferruccio 26.10.2008 12:24:59

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

  • Реализация оконных форм сейчас довольно хороша. (См. Paint-Mono для порта Paint.net, который является довольно сложным приложением для Windows-форм. Все, что требовалось, - это слой эмуляции для некоторых P-Invoke и неподдерживаемых системных вызовов).
  • Path.Combine, а также Path.Seperator для объединения путей и имен файлов.
  • Реестр Windows в порядке, если вы используете его только для хранения и извлечения данных из ваших приложений (т. Е. Вы не можете получить от него никакой информации о Windows, поскольку это в основном реестр для приложений Mono).
21
31.08.2008 16:53:49
+1 за продолжение ... похоже, эта страница может снова устареть.
harpo 8.07.2010 02:25:30
Да, два года - это целая жизнь в Моно со скоростью, с которой работают эти парни.
Kris Erickson 8.07.2010 14:01:26

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

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

12
22.01.2009 20:54:46
Это действительно очень плохо. WPF - достойный инструментарий пользовательского интерфейса.
JP Richardson 30.08.2009 07:21:09
@JP Richardson Я понимаю, к чему ты клонишь - это здорово, когда программируешь, - но я бы не назвал это «приличным», если он построен с самого начала с намерением стать непереносимым инструментарием.
Wyatt8740 30.06.2019 14:17:57
@ Wyatt8740 мой комментарий был написан 10 лет назад.
JP Richardson 1.07.2019 20:42:59
@JP Ричардсон лол, мой плохой. Но он все еще не должен был быть портативным даже десять лет назад.
Wyatt8740 3.07.2019 02:33:30

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

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

2
23.10.2008 17:35:00

Для типа приложения, которое мы создаем, к сожалению, 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, но это просто увеличивает порог, до которого происходит сбой.

2
24.10.2008 11:58:34
Bugzilla - это место, где можно сообщать об ошибках: Мигель чрезвычайно занят, и никто не может поспеть за тем, чтобы каждый отправлял ему отдельные сообщения об ошибках. Если вы не можете опубликовать пример кода, вы все равно должны сообщить о проблеме в bugzilla и заметить, что вы отправили образец Мигелю или мне (lupus@ximian.com).
lupus 27.10.2008 08:27:06

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

2
26.10.2008 12:17:59

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

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

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

Однажды / во время получения ваших вещей фактически СОЗДАННЫХ, вы можете увидеть некоторые проблемы даже для кода, который СЛЕДУЕТ поддерживать, например:

  • компилятор не справляется с определенными конструкциями
  • и некоторые более продвинутые / новые классы .NET бросают в вас неожиданную чушь (XLinq кто-нибудь?)
  • некоторые незрелые «особенности» времени выполнения (ограничение кучи в 3 ГБ ПО x64 ... WTF!)

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

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

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

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

23
5.11.2008 12:21:17
Вы можете сказать мне (если можете), о каком веб-сайте вы говорите?
Christophe Debove 15.10.2012 15:39:26

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

1
12.06.2010 21:43:03
Это анекдотическое доказательство, представленное как факт, и мне кажется, что FUD
firegrass 23.04.2013 11:32:31
На самом деле ASP.NET может работать быстрее под nginx / fast-cgi, чем на IIS. Все зависит от того, какая часть фреймворка перенесена / хорошо протестирована: mono-project.com/Compatibility . Должен согласиться с @firegrass.
Rui Marques 22.05.2013 14:36:17
Это личный опыт одного человека, представленный как таковой. За исключением добавления префикса «я думаю», это верный вклад в это обсуждение.
Amir Abiri 3.02.2014 10:14:47

Ну, моно это здорово, но, насколько я понимаю, оно нестабильно. Это работает, но дает сбой, когда вы даете моно процессу серьезную работу.

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

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

Итак, факты.

Мы используем 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

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

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

  • Sgen GC обрабатывает ошибки практически мгновенно
  • Моно с Бёмом живет дольше (от 2 до 5 часов), но в конечном итоге segfaults

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

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

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

9
26.09.2013 07:02:32
Вы пытались зарегистрировать ошибку в Xamarin bugzilla ?
MiKom 9.03.2014 10:38:28
head_thrash 10.03.2014 11:54:22
head_thrash 10.03.2014 11:55:03