Требуются: пользовательский опыт работы с C # (моно) в MacOS и Linux - PullRequest
5 голосов
/ 14 февраля 2011

У меня есть друг, который был серьезным разработчиком Linux, но теперь он работает с C # на Windows и действительно любит его. Меня привлекает C #, потому что, как и Java, я должен иметь возможность компилировать в одной системе и запускать где угодно.

Если вы разрабатываете на Windows с C #, вы используете dot-Net. В Linux и MacOS вы используете Mono.

Другие люди сообщали, что Mono довольно хорош, больше не является научным проектом, и что присутствует большая часть основных функций Microsoft. Но это не совсем касается вопросов, которые у меня есть. Мне интересно:

  1. Как производительность Mono в Linux / MacOS отличается от Java? Если я хочу быстро работать на всех трех платформах с одним и тем же объектным кодом, какой мой лучший выбор?
  2. Легко / возможно / разумно ли использовать Mono с make-файлами и делать мою разработку с emacs?
  3. Есть ли поддержка факторинга кода в MacOS и Linux, или мне лучше просто прикусить пулю и заняться всей моей разработкой в ​​Windows?
  4. Насколько хорошо Mono работает с Subversion и остальным стеком разработки с открытым исходным кодом? Как насчет autoconf? Или это совершенно другой способ ведения дел?

Спасибо

1 Ответ

10 голосов
/ 03 марта 2011

Я использую Mono в Linux около трех лет, и в последнее время использую его в OS X. Некоторые из компонентов Linux были довольно обширными, но до сих пор OS X были просто простыми приложениями ASP.NET MVC2.

1) Производительность Mono никогда не была для меня проблемой.Это не означает, что производительность не была важной, просто производительность самой Mono никогда не была проблемой.Многое из того, что я сделал, - это веб-интерфейс, поэтому использование ввода-вывода и памяти базы данных поразило меня раньше, чем Mono.

Исторически самым большим недостатком Mono был сборщик мусора (GC).Я бы сказал, что Java лучше настроена в этом отношении.Самые последние версии Mono добились огромных успехов в этой области, но у меня нет для вас точных цифр с точки зрения сравнений.

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

2) Конечно, вы можете заниматься разработкой Mono с помощью make-файлов.Конечно, сама команда Mono делает.Также вы можете использовать Emacs, и для него есть режим C # .

Я обычно использую MonoDevelop и xbuild (Mono-версия msbuild) и не имею опыта работы с C #в Emacs.MonoDevelop великолепен, потому что он одинаков на всех платформах.Кроме того, хотя я редко использую его больше, приятно, что формат проекта совпадает с форматом Visual Studio и SharpDevelop.

3) MonoDevelop имеет довольно приличную поддержку кодового факторинга.То же самое на Windows, Linux и Mac.Вам не нужно использовать Windows для разработки (хотя вы, безусловно, можете), но я думаю, что вы будете счастливее, используя IDE, такую ​​как MonoDevelop.Даже такие вещи, как Intellisense, становятся трудными для жизни без того, чтобы привыкнуть к ним.Но интегрированная отладка, возможность детального изучения инфраструктуры, интеграция с базой данных, модульное тестирование, интеграция SCM и другие полезные инструменты - все это в одном месте (по крайней мере, для меня).

4) Само Mono, конечно, не заботится о контроле версий.Ваши исходные файлы - просто текст, и вы можете использовать все, что угодно, чтобы управлять ими.

При этом MonoDevelop имеет фантастическую поддержку Subversion, встроенную прямо в IDE.Я широко использовал его, и это одна из причин, по которой у меня возникают проблемы при переходе с MonoDevelop даже на Windows.Последняя версия MonoDevelop (бета-версия 2.6) также включает поддержку Git.

Вы не упомянули модульное тестирование, но MonoDevelop также имеет встроенную поддержку NUnit в IDE.Я использую это и в каждом проекте, и он отлично работает.Версия в MonoDevelop - 2.4.8 (если память используется), поэтому она не совсем актуальна, но работает отлично.

В двух словах, Mono очень хорошо работает с инструментами с открытым исходным кодом в целом.Он всегда играл очень хорошо для меня.

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

Я знаю, что MonoDevelop будет создавать файлы autoconf / autorun для проектов C / C ++ (не Mono), но я этого не сделалМногое с этим.

Что касается предыдущего комментария, Mono JIT явно настроен на целевую платформу.Именно здесь происходит настройка производительности для конкретной платформы.

В качестве комментария я обнаружил, что Mono лучше всего рассматривать как самостоятельную среду разработки, а не как слой совместимости для Microsoft.Команда Mono расширила .NET многими интересными способами.Все, что вы разрабатываете для Mono, будет работать на .NET, но есть некоторые функции .NET, недоступные для Mono.Например, Mono не поддерживает Windows Presentation Foundation (WPF).Вы должны использовать Windows Forms или GTK # для работы с кросс-платформенным графическим интерфейсом.Вы также можете использовать что-то вроде Cocoa # или MonoMac на Mac, MonoTouch на iPhone или MonoDroid для Android.Вы также можете использовать Moonlight вместо Silverlight, хотя я не слишком много с ним играл.

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

Итак, поехали, один реальный ответ для вас, по крайней мере.

...