Моно готово к прайм-тайм?


312

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

+16

Mindtouch.com использует C# на Mono на Debian для очень надежной вики-платформы. Пойдите, проверьте их. Вы даже можете загрузить предварительно сконфигурированную виртуальную машину, которую вы можете легко настроить и использовать. 17 ноя. 082008-11-17 06:09:32

+6

Я нашел, что наилучшее использование моно может сказать: «Если Microsoft делает XXX, мы можем перейти к моно на unix ...» 07 фев. 112011-02-07 17:25:46

+4

Я думаю, что этот вопрос заслуживает того, чтобы его перепросили, учитывая все, что изменилось с тех пор вот этот. 16 июн. 142014-06-16 23:28:22

400

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

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

Если ваша оценка вернулась с сообщением, в котором выделяются функции, которые отсутствуют или существенно отличаются по своей семантике в 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/вызывать их мозги, чтобы настроить такие вещи, как полезное, как изменение скорости мигания курсора, выраженное в виде двух точек безье, закодированных в форме BCD, в WPARAM. Или какой-то хлам.

  0

Невероятный ответ, спасибо! 24 окт. 082008-10-24 12:05:57

+1

Мигель снова у него;) Отличная работа! 26 окт. 082008-10-26 15:40:07

+270

Кто этот парень думает, что он? создатель моно ??? !! ... o wait .. 26 дек. 082008-12-26 17:32:00

+2

Есть ли эквивалент LINQ в моно? Потому что я разработчик .net и в основном не использую linux из-за этой проблемы (среди прочего) 20 янв. 092009-01-20 22:04:06

+14

@Drahcir: LINQ работает над Mono. Это не Windows. Так что продолжайте и попробуйте Linux. 20 май. 092009-05-20 23:34:59

+30

", так же полезно, как изменение скорости мигания курсора, выраженное в двух точках безье, закодированных в форме BCD, в wParam" lol 25 окт. 092009-10-25 17:24:11

+10

Большое вам спасибо за Mono ... 24 июн. 102010-06-24 01:23:31

  0

@theman_on_vista: lol 25 июн. 102010-06-25 01:23:18

+4

Довольно справедливый и правдивый ответ, учитывая Мигель - создатель моно. Но хотя он точно для asp.net, он не говорит, что даже если winforms runtime реализовано и работает правильно, большую часть времени он не выглядит/не делает достаточно хорошим для продажи ваших моно приложений. Для этого вам нужно использовать GTK #. И поддержка от моно исполнения - это еще не все. Если какой-то придурок использовал разделители окон, а не system.io.path.directoryseparatorchar, он не будет работать из коробки, и это также относится к разнице в именах файлов в верхнем нижнем регистре. Последнее, что особенно важно для сторонних инструментов 08 авг. 102010-08-08 13:47:54

  0

Чтобы быть справедливым, этот вопрос был опубликован в 08. С тех пор, я считаю, что многие созрели. Есть также порты XNA и Monotouch, которые кажутся многообещающими. 09 мар. 112011-03-09 19:32:53

  0

> Реализация Windows.Forms по-прежнему немного затруднительна. Знаете ли вы, насколько хороша поддержка предварительного просмотра Mono 2.0 для Windows Forms 2.0? 20 авг. 082008-08-20 18:19:47

+26

miguel, было бы неплохо получить обновление на этом посту ;-) 13 янв. 122012-01-13 08:33:46

  0

Стоит иметь в виду, что существует огромное различие между настольным приложением и серверным кодом. Если у вас есть REST API или какой-либо искатель веб-сайтов или вероятность сокращения числа, вы можете скопировать его прямо сейчас на сервер Ubuntu и запустить его. 05 янв. 142014-01-05 16:16:17

  0

@ miguel.de.icaza [Будет ли .NET ядро ​​в конечном итоге заменять Моно в будущем?] (Http://stackoverflow.com/questions/34638105/how-to-port-to-net-core#comment57028604_34638105) 20 янв. 162016-01-20 14:52:12

+1

Является ли Moma up -встретиться? 10 фев. 162016-02-10 20:07:29


4

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

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


38

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

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

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

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

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

Почему GTK # лучше? 25 фев. 092009-02-25 16:54:32

+2

Path.Separator - хороший совет, кроме Mono на OS X есть ':', а не '/'! Ха! Это старый разделитель Mac OS (<= 9.0). Wha? Unix - это все. 05 июн. 102010-06-05 07:29:06

+3

Я не беспокоюсь о Environment.NewLine или Path.Separator, просто используйте/и \ n. Каждая настольная система, которая в настоящее время пользуется популярностью (если только я ее не хватает), использует/и \ n. Windows предпочитает \ и \ r \ n, но с радостью будет использовать unix. 04 авг. 132013-08-04 13:29:22


65

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

  • Windows Presentation Foundation
  • Windows Workflow Foundation (ни одна из двух версий)
  • Entity Framework
  • WSE1/WSe2 "дополнения" к стандартный стек Web-сервисов

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

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

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

Моно активно используется в several commercial as well as open source products. Он используется в некоторых крупных приложениях, таких как Wikipedia and the Mozilla Developer Center, и использовался во встроенных приложениях, таких как MP3-плееры Sansa и поддерживает тысячи опубликованных игр.

На уровне языка, the Mono compiler is fully compliant with the C# 5.0 language specification.


1

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

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

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


2

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

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


1

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

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


4

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

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

  0

Итак, как вы пишете код для последовательных портов, который обрабатывает оба? Вся суть CLR/Mono должна быть независимой от платформы, не так ли? Это делается в конфигурационных файлах? 12 янв. 092009-01-12 04:46:17


5

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

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

+4

Это анализатор переноса моно для всех, кто почесывает голову, думая, что это имеет отношение к Музею современного искусства. 26 окт. 082008-10-26 12:24:59


21

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

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

+1 для последующих ... похоже, эта страница может быть устаревшей еще раз. 08 июл. 102010-07-08 02:25:30

+1

Да, два года - это жизнь в Моно со скоростью, с которой работают эти парни. 08 июл. 102010-07-08 14:01:26


12

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

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

+3

Это действительно так плохо. WPF - достойный набор инструментов пользовательского интерфейса. 30 авг. 092009-08-30 07:21:09


2

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

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


2

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

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

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

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

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

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

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

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

+9

Bugzilla - это место для сообщения об ошибках: Мигель чрезвычайно занят, и никто не может идти в ногу со всеми, кто отправляет ему отдельные отчеты об ошибках. Если вы не можете опубликовать образец кода, вы должны сообщить об ошибке в bugzilla и отметить там, что вы отправили образец Мигелю или мне ([email protected]). 27 окт. 082008-10-27 08:27:06


2

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


23

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

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

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

Однажды/Во время получения ваших вещей на самом деле построены, вы можете увидеть некоторые даже для места дикой природы коды, который должен быть поддержан как:

  • компилятора получать BORKED на некоторых конструкциях
  • и некоторые более продвинутые/нового .NET классов метания ип ожидалось дерьма на вас (? XLinq кто)
  • некоторой незрелое времени выполнения «функция» (3GB ограничение кучи ON x64 ... WTF!)

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

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

У меня были серверы, работающие с моно, обрабатывающие 300 ГБ данных в день, с тоннами p/invokes и, вообще говоря, много работы и оставаясь UP в течение 5-6 месяцев, даже с монохроматическим краем ,

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

+1

Можете ли вы рассказать мне (если можете), на каком веб-сайте вы говорите? 15 окт. 122012-10-15 15:39:26


1

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

+4

Это анекдотическое доказательство, представленное как факт, и встречается со мной как FUD 23 апр. 132013-04-23 11:32:31

  0

На самом деле ASP.NET быстрее работает под nginx/fast-cgi, чем в IIS. Все зависит от того, какая часть каркаса перенесена/проверена: http://www.mono-project.com/Compatibility. Должен согласиться с @firegrass. 22 май. 132013-05-22 14:36:17

+1

Это личный опыт человека, представленный как таковой. За исключением того, что он префикс «Я думаю», это действительный вклад в эту дискуссию. 03 фев. 142014-02-03 10:14:47


9

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

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

  • использование AppDomains (Актовый Load \ Выгрузить) в многопоточных средах
  • может не выдержать 'пусть-это обанкротиться' модель
  • Испытайте случайные события большой нагрузки во время технологического цикла

Итак, факты.

Мы используем mono-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 и пытается выполнить некоторую математическую работу. Некоторая работа многопоточная, некоторые - одиночные. Почти вся работа связана с CPU, хотя есть некоторые чтения файлов с диска.

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

  • sgen процесса GC почти немедленно возвращает ошибку сегментации
  • моно с Бем живет дольше (от 2 до 5 часов), но в конечном счете
  • возвращает ошибку сегментации

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

* 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] 

Что касается Бем 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, моно взят из оборотов в минуту здесь 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 без каких-либо сбоев.

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

  0

Вы пробовали подавать ошибку в [Xamarin bugzilla] (https://bugzilla.xamarin.com/index.cgi)? 09 мар. 142014-03-09 10:38:28

+2
+2