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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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