Должен ли я использовать Mono в реальном проекте?

Question

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

Answer 1

Я с большим успехом использовал его для ряда внутренних и коммерческих проектов. Мои предупреждения:

• Напишите множество юнит-тестов и убедитесь, что они ВСЕ проходят под Mono - это избавит вас от многих проблем.
• Если вам абсолютно не нужно, НЕ используйте их API встраивания. Его чертовски легко использовать, но безбожно легко собирать действительную память или тратить всю вашу память.
• Никогда, никогда, даже близко не подходите к SVN и, если нет выбора, не собирайте свой собственный. В SVN все меняется так часто, что вполне вероятно, что в конечном итоге вы реализуете что-то, что не работает в версии выпуска, если ваш проект значительно велик.
• Не пытайтесь самостоятельно долго решать проблемы, используйте IRC-канал. Люди там полезны, и ты будешь спасать себя дни за днем ​​- не делай ту же ошибку, что и я.

Удачи!

Редактировать: Причина, по которой я говорю не компилировать ваш собственный из исходного кода (релиз или SVN), заключается в том, что его легко настроить иначе, чем выпускать двоичные файлы и скрывать ошибки, например, в сборке мусора.

Редактировать 2: Забыли ответить на вторую часть на ваш вопрос. В моем случае у меня не было проблем с переносом кода, но я не использовал никаких специфичных для MS библиотек (WinForms, ASP.NET и т. Д.). Если вы используете только System. *, Все будет хорошо; кроме этого, вы можете столкнуться с проблемами. Mono 2.0 довольно солидный.

Answer 2

У меня был некоторый опыт работы с Mono.

Чистые вещи .NET (такие как бизнес-логика, контроллеры или алгоритмы) могут быть перенесены без каких-либо проблем. Тем не менее, странные вещи начинают обнаруживаться в компонентах, которые взаимодействуют с операционной системой, пользовательским интерфейсом, службами или постоянством. , Так что будьте готовы к некоторой отладке и взлому.

Что может помочь:

• Компонентно-управляемая разработка - чтобы код повторно использовался Windows .NET и Mono, а различия были изолированы и проверены)
• Непрерывная интеграция запуск и проверка всего на Mono и MS.NET, чтобы возможные проблемы могли быть обнаружены как можно быстрее (также рекомендуется автоматическое развертывание и проверка работоспособности)
• В Mono не так много наборов компонентов пользовательского интерфейса для разработки оболочки.
• Когда поставщик компонента говорит, что его код «совместим с Mono», он не совпадает с «работает на Mono и поддерживается».

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

• Отсутствие приличных и коммерчески поддерживаемых комплектов компонентов пользовательского интерфейса
• Проблемы с эффективной сборкой мусора
• Не лучший опыт отладки (сравните с историческим отладчиком в VS 2010)

PS: если есть компания, предлагающая полностью управляемое решение для облачных вычислений (не просто виртуальная машина, а скорее аналог Hadoop для .NET), тогда я буду вынужден вмешаться, несмотря на эти проблемы.

Answer 3

Я считаю, что Mono в основном двоично совместим с MS. Поэтому я просто компилирую с MS и запускаю где угодно, как и должно быть в Java!

Производительность Mono в Linux очень близка к MS, в некоторых случаях она всего в 2 раза медленнее, а при запуске Mono в Windows - в 5-10 раз (но вам действительно следует придерживаться MS). *

Answer 4

Если вы работаете с ASP.NET 2.0, он работает очень хорошо. Winforms может работать, но это может вызвать проблемы с отображением. Если вы хотите совместимости в приложении форм, я бы предложил GTK #, так как он кроссплатформенный.

Как и предполагалось, до тех пор, пока вы проводите тщательное тестирование, я бы согласился использовать его на коммерческой основе, если это приемлемый вариант для вас, если только вам не нужны формы winform. На мой взгляд, я бы пока держался подальше от этого. И забудьте о WPF, так как в настоящее время нет поддержки, и, возможно, ее никогда не будет (хотя они работают над лунным светом, он же silverlight для linux)

Answer 5

Я сам не использовал Mono, но вам может быть интересно узнать, что FogBugz использует Mono для предоставления Lucene.NET на платформах Linux. (Я знаю это только потому, что Джоэл упомянул об этом в подкасте Stack Overflow № 24).

Answer 6

Конечно, вы можете, особенно после выхода Mono 2.0. Mono 2.0, готов к реальным проектам.

Вы можете проверить это

Answer 7

Я использовал его для инструментов шифрования / дешифрования, и он работал нормально.

В будущем я хотел бы рассмотреть возможность использования Mono / C #, но не ожидал, что он будет на 100% точно подобен .Net в Windows.

Answer 8

У меня есть куча приложений оболочки.

Я согласен с @ cody-brocious, напишу много юнит-тестов. В прошлом я обнаружил, что регулярные выражения не работают точно так же, как Windows CLR.

На самом деле проще, чем вы думаете, просто скомпилировать и запустить. Если вы используете NAnt в своих проектах, переход становится еще проще.

Обычно я устанавливаю mono из исходных версий, и у меня не было проблем.