Для корпоративных решений на базе Windows .NET иногда является лучшим выбором. Как на Mono смотрят предприятия, которые должны использовать Linux (или, скорее, предпочитают использовать Linux)? Предполагая, что разработчики не проблема, и они знакомы с .NET / Mono и другими возможными конкурентами, такими как Java.
Будет ли средняя / крупная компания запускать Mono на своих серверах в отличие от таких технологий, как Java? Вы знаете какую-нибудь такую компанию?
Мы использовали его в большой корпорации, где я работаю. Мы не планировали это с самого начала проекта, но это просто сработало.
У нас был внутренний проект, который мы разработали в .NET, и как только мы вошли в UAT, владелец бизнеса захотел открыть приложение для некоторых клиентов, а также для внутреннего персонала. Большинство наших внешних (DMZ) серверов основаны на Linux, и серверы Windows, которые находятся в DMZ, не подходили (слишком близко к емкости). Вместо покупки нового оборудования кто-то предложил запустить приложение на Mono. Мы провели пару дней, проводя собственное тестирование, а затем выпустили приложение в QA, а затем в UAT. У нас не было проблем.
Если бы нам дали требование в начале проекта, мы могли бы не написать его в .NET, но это был один хороший результат очень и очень позднего изменения требований. Теперь мы уверены, что если он снова появится, мы сможем успешно развернуть его в Mono (хотя я думаю, что в конечном итоге нам придется немного подправить код, думаю, нам просто повезло).
Я не использовал моно в коммерческих целях, но я использую его в частном порядке, потому что я работаю в компании Windows, но в частном порядке я пользователь Linux (поэтому я могу повторно использовать то, что я делаю на работе).
В целом, я согласен с Мигелем де Иказа, который говорит:
Mono работает довольно хорошо, но есть некоторые проблемы:
Тогда второстепенные проблемы:
Форма, что я могу сказать:
Если вы хотите разрабатывать .NET на Linux
Другими словами:
Редактирование (обновление 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.
источник