Моно часто використовується для того, щоб говорити "Так, .NET - кросплатформна". Наскільки ця заява справедлива? [зачинено]

В чим би ви вибрали для свого проекту між .NET і Java в даний момент часу? Я кажу, що я б розглядав "Чи завжди ви будете розгортатися в Windows?" єдине найважливіше технічне рішення, щоб зробити новий проект у новому веб-проекті, і якщо відповідь "ні", я б рекомендував Java замість .NET.

Дуже поширений контр-аргумент полягає в тому, що "Якщо ми коли-небудь захочемо працювати на Linux / OS X / Що б там не було, ми просто запустимо Mono" ¹ , що є дуже переконливим аргументом на поверхні, але я не згоден у кількох причини.

• OpenJDK і всі постачальники JVM, що постачаються, пройшли офіційний Sun TCK, забезпечуючи, щоб все працювало правильно. Мені не відомо, що Mono передає Microsoft TCK.
• Моно слідкує за версіями .NET. Який .NET-рівень на сьогодні повністю підтримується?
• Чи всі елементи графічного інтерфейсу (WinForms?) Правильно працюють у Mono?
• Підприємства можуть не захотіти залежати від систем відкритого коду як офіційного плану B.

Я знаю, що з новим управлінням Java від Oracle майбутнє небезпечно, але, наприклад, IBM надає JDK для багатьох платформ , включаючи Linux. Вони просто не відкриті.

Отже, за яких обставин Mono є дійсною бізнес-стратегією для .NET-додатків?

¹ _{Марк Н резюмував це як : "Якщо у претензії є те, що " у мене програма Windows написана в .NET, вона повинна працювати на моно " , то ні, це не є дійсною заявою - але Mono доклало зусиль, щоб зробити перенос таких програм простіше ".}

Відповідь Спаркі отримала це, дозвольте мені трохи доповнити.

".NET - крос-платформа" - це занадто неоднозначне твердження, оскільки і рамки, і світ, для якого він був створений спочатку, змінилися і еволюціонували.

Коротка відповідь:

Основний двигун, що використовує .NET та його похідні, загальний стандарт інфраструктури мови, є кросплатформенним, і як би ви хочете змусити ваш код перейти на кілька платформ, вам потрібно планувати використання правильних API на правій платформі для доставки найкращий досвід на кожній платформі.

Сім'я CLI не пробувала підходу "Написати один раз, запустити будь-де", оскільки відмінності від телефону до мейнфрейму занадто великі. Натомість з'явився універсал API та функцій виконання, які залежать від платформи, щоб надати розробникам потрібні інструменти для створення чудового досвіду на кожній платформі.

Подумайте: програмісти більше не орієнтуються на ПК з Windows або Unix-сервери. Зараз світ, як ніколи, оточений захоплюючими платформами від ПК, ігрових консолей, потужних телефонів, телевізорів, великих серверів та розподілених кластерів машин. Одномісний розмір на всій платформі міг би просто відчувати себе роздутим на крихітних пристроях та відчувати себе недостатнім у великих системах .

Продукт Microsoft .NET Framework не є платформою, він працює лише в Windows. Існують варіанти .NET Framework від Microsoft, які працюють в інших системах, таких як Windows Phone 7, XBox360 та браузерах через Silverlight, але всі вони трохи відрізняються за профілями.

Сьогодні ви можете орієнтуватися на всі основні ОС, телефон, мобільний пристрій, вбудовану систему та сервер за допомогою технологій на основі .NET. Ось список, який показує, яку реалізацію CLI ви використовували б у кожному випадку (цей список не є вичерпним, але повинен охоплювати 99% випадків):

• ПК на базі x86 та x86-64:
  • під керуванням Windows -> Зазвичай ви запускаєте .NET або Silverlight, але тут також можна використовувати повний Mono.
  • під управлінням Linux, BSD або Solaris -> Ви запускаєте повний Mono або Silverlight
  • під керуванням MacOS X -> Ви запускаєте повний Mono або Silverlight
  • працює Android -> Ви запускаєте Mono / підмножину Android
• ARM-комп’ютери:
  • Запуск Windows Phone 7: ви запускаєте Compact Framework 2010
  • Запуск Windows 6.5 і новіших версій: ви запускаєте старий Compact Framework
  • Android пристрої: ви запускаєте Mono / Android
• Комп'ютери PowerPC:
  • Ви запускаєте повне Mono для повних операційних систем Linux, BSD або Unix
  • Ви запускаєте вбудований Mono для PS3, Wii або інших вбудованих систем.
  • На XBox360 ви запускаєте CompactFramework
• Комп'ютери S390, S390x, Itanium, SPARC:
  • Ви запускаєте повний Mono
• Інші вбудовані операційні системи:
  • Ви запускаєте .NET MicroFramework або Mono за допомогою мобільного профілю.

Залежно від ваших потреб вищезазначеного може бути достатньо чи ні. Ви навряд чи отримаєте той самий вихідний код, який можна працювати всюди Наприклад, код XNA не буде працювати на кожному робочому столі, тоді як .NET Desktop не буде працювати на XNA або телефоні. Зазвичай потрібно внести зміни в код, щоб запустити їх в інших профілях .NET Framework. Ось кілька профілів, про які я знаю:

• Профіль .NET 4.0
• Профіль Silverlight
• Профіль Windows Phone 7
• Профіль XBox360
• Mono core Profile - відповідає профілю .NET і доступний у Linux, MacOS X, Solaris, Windows та BSD.
• .NET Micro Framework
• Моно на профілі iPhone
• Моно в профілі Android
• Моно на PS3 профіль
• Моно на профілі Wii
• Профіль місячного світла (сумісний із Silverlight)
• Розширений профіль Moonlight (Silverlight + повний доступ до API .NET 4)

Тож кожен із цих профілів насправді трохи інший, і це не погано. Кожен профіль призначений для розміщення на його хост-платформі та відкриття API, які мають сенс, та видалення тих, які не мають сенсу.

Наприклад, API Silverlight для управління хост-браузером не мають сенсу в телефоні. А шейдери в XNA не мають сенсу для апаратного забезпечення ПК, якому не вистачає еквівалентної підтримки.

Чим раніше ви зрозумієте, що .NET не є рішенням ізолювати розробника від основних можливостей апаратного забезпечення та рідної платформи, тим краще вам буде.

По-перше, деякі API та стеки доступні на багатьох платформах, наприклад, ASP.NET можна використовувати в Windows, в Linux, Solaris, на MacOS X, оскільки такі API існують і в .NET, і в Mono. ASP.NET не доступний на деяких підтримуваних Майкрософт платформах, таких як XBox або Windows Phone 7, і не підтримується ні на інших платформах, які Mono підтримує, як Wii або iPhone.

Наступна інформація правильна лише з 21 листопада, і багато речей у світі Моно, ймовірно, зміниться.

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

Основний двигун виконання [скрізь]

• Reflection.Emit Support [всюди, крім WP7, CF, Xbox, MonoTouch, PS3]
• Підтримка CPU SIMD [Linux, BSD, Solaris, MacOS X; Незабаром PS3, MonoTouch та MonoDroid]
• Продовження - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Вивантаження з монтажу [лише для Windows]
• Інжекція VM [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Загальна інформація [деякі обмеження для PS3 та iPhone].

Мови

• C # 4 [скрізь]
• Компілятор C # як послуга (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [скрізь, execpt WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [скрізь, execpt WP7, CF, Xbox, MonoTouch, PS3]
• F # [скрізь, крім WP7, CF, Xbox, MonoTouch, PS3]

Серверні стеки

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [скрізь]
• LINQ в SQL [всюди]
• Entity Framework [скрізь]
• Core XML стек [скрізь]
  • XML-серіалізація [скрізь, крім WP7, CF, Xbox)
• LINQ - XML ​​(скрізь)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; для Linux, MacOS та Solaris потрібен RabbitMQ]
• .NET 1 Enterprise Services [лише для Windows]
• WCF [завершено в Windows; невеликий підмножина на Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
• Windows Workflow [лише для Windows]
• Ідентифікація карткового простору [лише для Windows]

Графічні стеки

• Silverlight (Windows, Mac, Linux - з Moonlight)
• WPF (лише для Windows)
• Gtk # (Windows, Mac, Linux, BSD)
• Форми Windows. (Windows, Mac, Linux, BSD)
• MonoMac - інтеграція до Native Mac (лише для Mac)
• MonoTouch - Інтеграція Native iPhone (лише iPhone / iPad)
• MonoDroid - Інтеграція на родних Android (лише для Android)
• API Media Center - лише для Windows
• Clutter (Windows та Linux)

Графічні бібліотеки

• GDI + (Windows, Linux, BSD, MacOS)
• Кварц (MacOS X, iPhone, iPad)
• Каїр (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Монотехнічні бібліотеки - перехресна платформа, можна використовувати в .NET, але вимагати побудови вручну

• Компілятор C # 4 як послуга
• Cecil - CIL Маніпуляція, робочий процес, інструментальне обладнання CIL, Linkers
• Бібліотеки RelaxNG
• Провайдерів баз даних Mono.Data. *
• Full System.Xaml (для використання в установках, де .NET не пропонує стек)

MonoTouch означає Mono працює на iPhone; MonoDroid означає Mono, що працює на Android; Порти PS3 та Wii доступні лише кваліфікованим розробникам Sony та Nintendo.

Прошу вибачення за відсутність формальності.

По-перше, вам слід розмежувати загальну мовну інфраструктуру (відкритий стандарт) та .NET (впровадження цього стандарту Microsoft). Mono - це реалізація CLI, і ніколи не претендує на "портативний .NET". Також мова C # є відкритим стандартом і не є чітко прив'язаною до .NET.

Я не знаю, чи є у Microsoft якийсь інструмент для перевірки відповідності виконання, але якщо вони є, я впевнений, що моно хлопці мають його та використовують.

Моно відстає від .Net, але ледве. Моно може запускати код C # 4.0 (поточна версія .NET). Крім того, Microsoft нещодавно зробила код DLR та всі бібліотеки з відкритим кодом (за ліцензією Apache 2.0), що дозволило моно використовувати мови, такі як IronPython, IronRuby, і F #, було відкритим вихідним кодом лише минулого тижня. Крім того, Microsoft регулярно випускає CTP майбутніх функцій у .NET, що дозволяє моно розробникам бути в курсі поточних версій версій.

У .NET існує ряд інструментів та розширень, наприклад, Код контракти. Вони не завжди повністю реалізовані в моно. (На даний момент, я думаю, є частковий валідатор контракту для «Требує контрактів»). Вони так чи інакше не використовуються в додатках .NET, але якщо їхня популярність збільшилася, так би зросла швидкість, з якою вони реалізуються в моно.

WinForms не є (повністю) портативними. Вони є специфічними .NET і не є частиною CLI. CLI не визначає конкретного набору віджетів. Однак існують набори віджетів між платформами (GTK # та Silverlight). Якщо ви писали заявку з нуля, маючи на увазі портативність, ви використовували б один із них, а не Winforms / WPF. Крім того, моно надає тонку обгортку для API Winforms - це дозволяє переносити існуючі програми Winforms у GTK # (без цілого перезапису).

Mono надає інструмент Mono Migration Analyzer (MoMA), який може взяти наявну програму .Net та розповісти про її мобільність. (наприклад, визначте використовувані бібліотеки, які не передаються, P / Invokes тощо).

Для підприємств, які не хочуть залежати від відкритого коду - моно можна повторно ліцензувати. Право власності на код, доданий до моно, передається новеллу, який може ліцензувати його іншими способами, окрім звичайної ліцензії LGPL (у будь-якому випадку дуже мало обмежень).

Що стосується твердження ".NET - портативний", я думаю, що це може бути справедливим твердженням, якщо ви пишете код з нуля і знаєте проблеми переносимості з фреймворком. Якщо твердження полягає в тому, що "у мене програма Windows написана в .NET, вона повинна працювати на моно", то ні, це не є дійсною заявою - але Mono доклало зусиль, щоб зробити перенос таких програм простішим.

По пункту:

• OpenJDK та всі постачальники JVM, що постачаються, пройшли офіційний Sun TCK, забезпечуючи, щоб все працювало правильно. Мені не відомо, що Mono передає Microsoft TCK.
  Існує специфікація, якій відповідає CLR Microsoft. Mono не є клоном CLR Microsoft, а скоріше реалізацією тієї самої специфікації. З одного боку, є ймовірність, що це призведе до ще більшої несумісності. На практиці це дуже добре спрацювало для моно.
• Моно слідкує за версіями .NET. Який .NET-рівень на сьогодні повністю підтримується?
  Оскільки документація на .Net передує фактичному випуску, монофактично завершила (не бета-версію) підтримку .Net 4 до офіційного випуску Microsoft. Крім того, моно виконує дуже гарну роботу з документування того, що речі не підтримуються, і у них є кілька інструментів, з якими ви можете зіткнутися з існуючим проектом, щоб допомогти вам знайти місця з можливістю несумісності.
• Чи всі елементи графічного інтерфейсу (WinForms?) Правильно працюють у Mono?
  Переважна більшість winforms працює чудово. WPF, не так вже й багато. Я чув, що те саме стосується Java - багато вдосконалених інструментів віджетів / gui не так добре підтримуються на всіх платформах.
• Підприємства можуть не захотіти залежати від рамки з відкритим кодом, як від офіційного плану B.
  Якщо це так, вони з Java точно не збираються, оскільки це ставить рамку з відкритим кодом ще вище в плані А.

Підсумовуючи це, якщо ви хочете створити додаток на багато платформ прямо зараз , немає нічого поганого в тому, щоб почати з монографії з початку роботи і використовувати це як свою основу. Ви навіть можете розгорнути моно в Windows, якщо хочете.

З іншого боку, якщо ви сьогодні шукаєте, як створити додаток для Windows, яке, на вашу думку, може знадобитися перехресною платформою в якийсь невідомий момент у майбутньому, ви, ймовірно, хочете скористатися рідними віджетами та інструментами Windows. .Net тут робить набагато кращу роботу, ніж Java, а моно - цілком прийнятний відкат у цьому сценарії.

Іншими словами: Так, ні. Якщо крос-платформа є всіляко важливою для вашого питання. Ні, моно не буде просто запускати кожну програму .Net, але ваше питання знаходиться в контексті нового проекту. Не потрібно багато роботи, щоб уникнути проблем з новими проектами та уникнути проблем сумісності, особливо якщо ви думаєте з точки зору розробки для моно, а не розробки для .Net.

Найбільше, однак, я думаю, що це неправильне питання в першу чергу. Якщо ви не будуєте нову команду розробників з нуля, ви починаєте з програмістів, які мають досвід в тій чи іншій галузі. Ваших найкращих результатів буде досягнуто завдяки тому, що вже знають ваші програмісти. Настільки ж важливим, як може скластись платформа для різних платформ, якщо у вас є команда, повною. Якщо у вас є команда, повна java-програмістів, ви не будете просити їх навчитися. Net для проекту лише для Windows. Будь-який із них був би горіхом.

Я працював з Mono, і я б сказав, що це так добре, як ви можете отримати альтернативну платформу, яка є відкритим кодом і не підтримується безпосередньо Microsoft. Якщо вам може бути зручно використовувати альтернативну платформу з відкритим кодом, наприклад Clojure або Scala, можливо, вам буде зручно користуватися Mono.

Рівень .NET, підтримуваний Mono, завжди можна знайти на сторінці Mono дорожня карта .

Чи всі елементи GUI працюють? Наскільки я знаю, вони це роблять, хоча я не вичерпно перепробував кожен елемент.

Моно ідентичний .NET? Ні. Я підозрюю, що тут і там будуть потрібні незначні (а може і основні) виправлення. Наразі ви не можете запускати Entity Framework, наприклад.

Як ціль, всесвіт .NET / mono рухається дуже швидко .

Кожні кілька років Microsoft виходить з неодмінними змінами та нововведеннями щодо мови, часу виконання та інфраструктури, що стосується .NET. Наприклад: Generics, LINQ, DLR, Entity Framework - з кожною новою редакцією Visual Studio, як правило, спостерігається досить значне збільшення набору функцій та корисності рамки, на яку вона націлена.

Хоча постійне вдосконалення фреймворку вітається, також проблематично, якщо ви хочете сумісність на кількох платформах. Платформи довгострокової підтримки, такі як Red Hat Enterprise Linux, рухаються надзвичайно повільно щодо прийняття нових технологій, і в будь-який момент часу на платформі Mono відбудуться значні вдосконалення, які відбулися лише за останні кілька місяців. Тож якщо ви хочете запускати речі, які будують круті діти, вам доведеться збирати Mono з нуля та керувати своїми патчами та оновленнями. Це не круто.

Java, з іншого боку, така ж застійна, як дитячий басейн. Тим більше, що це власність компанії, яка просто захотіла Java для патентних позовів, ви можете бути впевнені, що в моєму майбутньому не буде помітних змін мови чи часу виконання. Java настільки ж стабільна платформа, як і FORTRAN. Це не так добре, якщо ви сподівалися на якісь вдосконалення, але не так вже й погано, якщо ви намагаєтесь розгорнути корпоративну програму.

З точки зору користувача, Mono допомагає зробити додатки Windows .NET сумісними з Linux. Якщо ви насправді намагаєтеся запустити будь-який гідно написаний додаток для Windows у Mono, це не вийде.

З точки зору пакувальника (я раніше трохи працював у PortableApps) .NET може бути і благом, і прокляттям. Якщо ви працюєте лише в Windows, .NET робить розгортання набагато простішим, оскільки більша кількість бібліотек означає менше системних речей (особливо це стосується версій Windows, я вважаю), але також є надзвичайно заплутаною навіть у Windows, оскільки версії .NET не є ні назад -сумісний або вперед сумісний. Вам потрібно завантажити різні версії .NET для різних програм.

З цього приводу, Mono - це прекрасна відправна точка для перетворення програм C # на багатопланову платформу. Просто не пакуйте програму найновішим WINE і не називайте її виконаною. Подивіться, куди це взяло Picasa.

Як і у випадку політичної стабільності двох мов / платформ, RMS, ймовірно, почав битися про те, як Mono очолює Novell, чий медовий місяць з Microsoft є досить відомим. Обидві платформи зараз можна вважати політично нестабільними.

Якщо ви дійсно хочете легкої крос-платформи, випробуваний і справжній шлях - це QT, який є досить стабільним в політичному плані, на даний момент це: a) LGPL'd, b) зроблено з його основними проблемами ліцензування минулих років, і c) підтримане Nokia, який продає дійсно дуже популярні телефони.

Моно не є портом .net Microsoft 1: 1. Є технології, які Mono просто не впроваджує або не планує цього робити (наприклад, Workflow Foundation або WPF ), а з іншого боку, вони мають власні технології, які Microsoft .NET не робить, наприклад, SIMD-розширення .

Короткий відповідь: Mono та Microsoft .NET базуються на одній основі - CIL та BCL - але це окремі проекти.

Невеликий коментар до тверджень в оригінальній публікації. Я заперечу, що TCK залишається теоретичним інструментом, що дозволяє Oracle заявляти про Java - це відкритий стандарт. Тому що якщо ви помітили, Apache Harmony вже кілька років безрезультатно намагаються отримати сертифікат "Java". Зрозуміло, що Oracle насправді не зацікавлений у застосуванні з відкритим кодом, окрім тієї, з якою вони пов'язані, і більш-менш контролю (OpenJDK), який btw. як Mono, не є повною (тобто немає підтримки Java Web Start) і не вистачає деяких оптимізацій, доступних у впровадженні закритого джерела HotSpot.

Так, певно, станом на 2010 рік; (більшість) Java є відкритим кодом, але не є відкритим стандартом, тоді як (більшість) .NET - це не з відкритим кодом, а з відкритим стандартом. Звичайно, є винятки, що DLR, IronPython, IronRuby і F # насправді є відкритим кодом. Моно цікава тим, що забезпечує найкраще з обох світів, реалізацію відкритих стандартів з відкритим кодом.

Відкладаючи всі технічні характеристики, дуже важлива частина відбувається при написанні коду.

Як і будь-яка міжплатформна технологія (будь то Java, Python, Ruby ...), якщо код записаний не з можливістю переносимості, ви повинні припустити, що в основному нульовий шанс коду запрацює належним чином (навіть якщо такий шанс є насправді набагато, набагато вище), оскільки дивна поведінка може бути досить критичною. Читайте: не приймайте випадкову збірку і не запускайте її під Mono.

І все ж для нового проекту (або одного, який ви можете легко рефакторувати), вибираючи .Net / Mono як потенційно портативний час виконання має сенс, але ви заощадите багато клопотів, перевіривши свій код на Mono дуже рано, навіть якщо проект має лише незначна зміна перехідної мультиплатформи. Якщо ви використовуєте сервер безперервної інтеграції, це може бути таким же простим, як і налаштування вузла Mono build. Багато питань можна вирішити під час розробки, просто створивши звичку з неї (як, наприклад, побудова рядків контуру), і величезний фрагмент вашого коду може бути переносним і перевіреним на Mono просто за допомогою розумних практик і трохи обміркованості. Решта (тобто невдалі тестові одиниці) потім залежать від платформи (наприклад, код, що використовує PInvoke), але має бути достатньо інкапсульована, щоб мати можливість запропонувати альтернативну реалізацію для цільової платформи.

Звичайно, використання бібліотеки, недоступної (.Net) або сумісної (третьої сторони) в Mono, перешкоджає будь-якому з цього, але в моєму полі це ще не було помічено. Це стратегія, яку ми насправді використовуємо на роботі, і, застосовуючи її, я не побоююся стверджувати, що. Net + Mono є крос-платформою.

Це різниця - це чесна відповідь. Я бачив, як дрібні веб-сервери перемістилися з IIS в Apache, працюючи під моно, майже без труднощів. Я запускав без змін програми Windows .Net, які успішно використовують Win Forms в Linux.

Однак, хоча це може працювати, якщо ви використовуєте виклик API, який не реалізований на моно, він не працюватиме, і єдиним рішенням є або переписати свою програму, дотримуватися вікон або писати зайві речі в моно.