Для корпоративных решений на базе Windows .NET иногда является лучшим выбором. Как на Mono смотрят предприятия, которые должны использовать Linux (или, скорее, предпочитают использовать Linux)? Предполагая, что разработчики не проблема, и они знакомы с .NET / Mono и другими возможными конкурентами, такими как Java.
Будет ли средняя / крупная компания запускать Mono на своих серверах в отличие от таких технологий, как Java? Вы знаете какую-нибудь такую компанию?
Ответы:
Мы использовали его в большой корпорации, где я работаю. Мы не планировали это с самого начала проекта, но это просто сработало.
У нас был внутренний проект, который мы разработали в .NET, и как только мы вошли в UAT, владелец бизнеса захотел открыть приложение для некоторых клиентов, а также для внутреннего персонала. Большинство наших внешних (DMZ) серверов основаны на Linux, и серверы Windows, которые находятся в DMZ, не подходили (слишком близко к емкости). Вместо покупки нового оборудования кто-то предложил запустить приложение на Mono. Мы провели пару дней, проводя собственное тестирование, а затем выпустили приложение в QA, а затем в UAT. У нас не было проблем.
Если бы нам дали требование в начале проекта, мы могли бы не написать его в .NET, но это был один хороший результат очень и очень позднего изменения требований. Теперь мы уверены, что если он снова появится, мы сможем успешно развернуть его в Mono (хотя я думаю, что в конечном итоге нам придется немного подправить код, думаю, нам просто повезло).
Я не использовал моно в коммерческих целях, но я использую его в частном порядке, потому что я работаю в компании Windows, но в частном порядке я пользователь Linux (поэтому я могу повторно использовать то, что я делаю на работе).
В целом, я согласен с Мигелем де Иказа, который говорит:
- 25% приложений .NET работают из коробки с моно
- еще 25% можно заставить работать в течение дня или меньше
- еще 25% можно заставить работать в течение недели
- Последние 25% требуют полного переписывания приложения (WinForms / COM)
Mono работает довольно хорошо, но есть некоторые проблемы:
- Поддержка VB.NET только для .NET <= 2.0
- Проверка подлинности Windows не реализована
- WPF не реализован
- Поддержка WCF неполная
- Entity Framework не реализована и нет планов по реализации
- «Веб-части ASP.NET» не реализованы
- Нет поддержки COM-взаимодействия
- Соединение Sybase для версии 15.5 (последняя) не работает
- Ошибки и неполнота в библиотеке классов C # (например, XML содержит ошибки в моно <2.6)
- Для управления веб-браузером в Linux требуется GTK #
Тогда второстепенные проблемы:
- Windows Forms работают, но не всегда отображаются правильно
- MonoDevelop не может проектировать формы окон
- MonoDevelop «пошаговая» отладка не работает
- Моносервис вылетает через 5 часов ...
Форма, что я могу сказать:
- Веб-сервисы отлично работают
- Если вы запускаете веб-приложение, оно работает довольно хорошо (если не использует веб-части).
- Если вы запускаете WindowsForms, он не всегда будет выглядеть очень хорошо (если не сказать больше).
- Не существует рабочего эквивалента для Microsoft Reporting Service (FYIreporting является наиболее близким к нему, но он медленный, глючный и очень неполный, плюс никакой активности больше года)
- У вас будут проблемы, если вам нужно будет создать документы Word или Excel.
Если вы хотите разрабатывать .NET на Linux
- Вы можете разработать ASP.NET там (отладка и пошаговая работа работает очень плохо)
- Вы действительно не можете разрабатывать WinForms в Linux
- Вам нужно использовать GTK # вместо WinForms
Другими словами:
- Mono имеет свое место в запуске веб-приложений и веб-сервисов и почтовых серверов.
- Но запуск приложений WindowsForms невозможен, вам нужно писать приложения с помощью GTK #
- В нем отсутствует решение для создания отчетов и поддержка формата файлов MS (или, следовательно, рабочих библиотек).
Редактирование (обновление 2015 г.):
я хотел добавить, что к настоящему времени отладка с пошаговым выполнением работает превосходно, и вы можете использовать MonoDevelop для разработки веб-приложений для Linux, даже с зависимостями nuGet. Проблема с библиотеками Excel и Word также исчезла, а Entity-Framework теперь с открытым исходным кодом. Остальное в значительной степени "как есть" (не знаю, исправлен ли моно-сервис, но я бы на это надеялся).
Также улучшилось то, что теперь вы можете иметь текущие пакеты для своего дистрибутива, то есть вам не нужно ждать следующего выпуска, скажем, Debian / Ubuntu, пока вы не получите последнюю моно версию (без необходимости компилировать их самостоятельно). ). Это значительно экономит время.
Кроме того, с выпуском Roslyn поддержка VB.NET должна стать намного лучше в ближайшем будущем.
Моя компания разрабатывает крупное настольное приложение .NET и выпускает версии для Linux, работающие на Mono, поэтому я бы сказал, что для корпоративных решений на базе Windows определенно есть место для Mono.
Мы устанавливаем Mono с установкой нашего приложения, не требуя, чтобы пользователи устанавливали его отдельно (и таким образом мы также контролируем версию).
Я думаю, что основной проблемой для многих корпораций будут проблемы с лицензией между Mono и Microsoft. Насколько я понимаю, Microsoft официально согласилась с тем, что Mono может использовать основные технологии .NET, но помимо этого, в том числе об очень часто используемых вещах, юридически это скорее серая область, и Microsoft не заявляет о своей твердой позиции в этом отношении. Другие.
Это, очевидно, оставляет открытой возможность того, что в будущем они будут требовать лицензионных сборов или просто предъявят иск за нарушение патента. Маловероятно, что то или другое произойдет из-за того, как они ведут себя сейчас, но большинству корпораций не нравится такая неопределенность, особенно когда речь идет о потенциальных обязательствах и связанных с этим издержках.
Я не думаю, что там есть много места для Моно:
Java уже является установленной платформой для Linux, с огромным сообществом и множеством библиотек и инструментов корпоративного качества, как коммерческих, так и открытых. Я не вижу смысла выбирать Mono над Java при запуске нового проекта, ориентированного на Linux (или Mac), если нет каких-то особых обстоятельств (см. Ответ Уолтера).
Перед использованием mono, мы должны убедиться, что в программе нет жестко закодированного '\' для строки пути (используйте префикс Path.Combine ()) или "COM" (просто принимайте строку вместо целого числа) для последовательного порта.
Что работает хорошо:
Возникли проблемы:
Лучше использовать моно внутри (например, система ERP) в качестве контролируемой среды.
Mono - отличная альтернатива, если у вас уже есть код .NET, который должен работать в кроссплатформенной среде. Mono довольно широко используется в деловом мире специально для решения этой самой проблемы.
Я бы поспорил против использования существования Mono в качестве предлога для запуска проекта с .NET, который, как вы знаете, должен быть кроссплатформенным. Причиной этого является несоответствие между современным уровнем развития .NET и скоростью разработки Mono.
С другой стороны, если вы действительно намерены использовать Mono в проекте будущего, я хотел бы предостеречь вас , чтобы предназначаться рамки Mono и запустить на .NET в качестве вторичной альтернативы , поскольку Mono в значительной степени является подмножеством полной функциональности .NET.