Для корпоративних рішень на основі 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)
Моно працює досить добре, але є деякі проблеми:
- Підтримка VB.NET лише для .NET <= 2.0
- Автентифікація Windows не реалізована
- WPF не реалізовано
- Підтримка WCF неповна
- Entity Framework не впроваджений і не планується впроваджувати
- "Веб-частини ASP.NET" не реалізовані
- Немає підтримки COM-interop
- Підключення Sybase для версії 15.5 (остання) не працює
- Помилки та неповнота в бібліотеці класів C # (наприклад, XML був помилковим у моно <2,6)
- Для керування веб-браузером Linux потрібен GTK #
Тоді незначні проблеми:
- Форми Windows працюють, але не завжди відображаються належним чином
- MonoDevelop не може розробляти форми Windows
- MonoDevelop "крок через" налагодження насправді не працює
- Моно-сервіс виходить з ладу через 5 годин ...
Сформуйте, що я можу сказати:
- WebServices чудово функціонують
- Якщо ви запускаєте WebApplication, він працює досить добре (якщо він не використовує WebParts).
- Якщо ви запускаєте 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 також відсутня, і сутність-фреймворк тепер є відкритим кодом. Решта в значній мірі "як є" (не знаю, чи встановлено моносервіс, але я би сподівався на це).
Також покращилось те, що тепер ви можете мати поточні пакети для вашого дистрибутива, тобто вам не потрібно чекати наступного випуску, скажімо, Debian / Ubuntu, поки ви не отримаєте останню моно-версію (без необхідності їх складання самостійно ). Це головне безпечніше в часі.
Крім того, з виходом Roslyn, підтримка VB.NET повинна найближчим часом стати набагато кращою.
Моя компанія розробляє основний настільний додаток для настільних комп'ютерів .NET та випускає версії Linux, що працюють на Mono, тому я б сказав, що так, Mono, безумовно, має місце для корпоративних рішень на базі Windows.
Ми пакуємо Mono при встановленні нашого додатку, не вимагаючи від користувачів встановлення його окремо (і таким чином ми також контролюємо версію).
Я думаю, що головне питання, яке викликає багато корпорацій, - це питання ліцензій між Mono та Microsoft. Я розумію, що в той час як Microsoft офіційно погодився, що Mono може використовувати основні технології .NET, але поза цим, у тому числі про дуже часто використовувані речі, це юридично більше сіра зона, а Microsoft не висловлює жодної твердої позиції з цього приводу. інший.
Це, очевидно, залишає відкритим можливість того, що вниз вони вимагатимуть ліцензійних платежів або просто пред'являть позов за порушення патенту. Малоймовірно, що це станеться з того, як вони поводяться зараз, але більшості корпорацій не подобається така невизначеність, особливо якщо це не стосується потенційних зобов'язань та витрат.
Я не думаю, що там багато місця для Моно:
Java вже створена платформа в Linux, яка має величезну спільноту та велику кількість корпоративних бібліотек та інструментів, як комерційних, так і відкритих. Я не бачу причин вибирати Mono над Java під час запуску нового проекту, орієнтованого на Linux (або Mac), якщо немає конкретних обставин (див. Відповідь Уолтера).
Перш ніж використовувати моно, ми повинні переконатися, що у програмі немає жорсткого коду "\" для рядка шляху (використовуйте префікс Path.Combine ()) або "COM" (просто прийняти рядок замість цілого) для послідовного порту.
Що добре працює:
Проблеми, що виникають:
Краще використовувати моно внутрішньо (наприклад, ERP-систему) як контрольоване середовище.
Моно - це чудова альтернатива, якщо у вас вже є .NET-код, який потрібно запускати на міжплатформенному середовищі. Моно використовується досить широко в діловому світі спеціально для вирішення цієї самої проблеми.
Я б заперечував проти використання існування Mono як привід для запуску проекту з .NET, який, як ви знаєте, повинен бути кросплатформенним. Причиною цього є відставання між найсучаснішим .NET від швидкості розвитку Mono.
З іншого боку, якщо ви дійсно маєте намір використовувати Mono в проекті майбутнього, я хотів би застерегти вас , щоб призначатися рамки Mono і запустити на .NET в якості вторинної альтернативи , оскільки Mono в значній мірі є підмножиною повної функціональності .NET.