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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

значительная часть А секрета поддержки Моно, я думаю, должна использовать правильные инструменты с начала, например, ActiveRecord, log4net, Ра-ajax и т.д.

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

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

Вы знаете, как поддержка хороших Моно 2,0 предварительных просмотров для Windows Forms 2.0?

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

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

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

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

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

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

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

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

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

• компилятор, добирающийся borked на определенных конструкциях
• и бесспорный больше усовершенствованных/новых классов.NET, бросающих неожиданное дерьмо в Вас (XLinq кто-либо?)
• некоторые незрелые "функции" во время выполнения (предел "кучи" на 3 ГБ НА x64... WTF!)

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

, Как только Вы пробежались через те начальные препятствия, мой опыт состоит в том, что моно СКАЛЫ, и сохраняют улучшение с каждым повторением .

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

Hope это помогает.

Если Вы хотите использовать WPF you'rr неудачливый Моно, в настоящее время не имеет никаких планов реализовать его.

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

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

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

Так или иначе, Моно является большим, и стабильным.

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

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

Это имеет довольно обширное покрытие до.NET 4.0, и даже включайте некоторые функции от.NET 4,5 API, но существует несколько областей, что мы выбрали not to implement due to the APIs being deprecated, новые создаваемые альтернативы или объем, являющийся слишком большим. Следующие API не доступны в Моно:

• Windows Presentation Foundation
• Windows Workflow Foundation (ни одна из этих двух версий)
• Платформа Объекта
• "дополнения" WSE1/WSE2 к стандартной стопке веб-сервисов

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

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

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

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

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

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

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

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