Моно часто используется, чтобы сказать «Да, .NET является кроссплатформенным». Насколько обоснован этот иск? [закрыто]

В Что бы вы выбрали для вашего проекта между .NET и Java на данный момент? Я говорю, что я бы подумал: «Будете ли вы всегда использовать Windows?» единственное самое важное техническое решение, которое стоит принять во внимание в новом веб-проекте, и если ответ «нет», я бы порекомендовал Java вместо .NET.

Очень распространенным контраргументом является то, что «если мы когда-нибудь захотим работать на Linux / OS X / что угодно, мы просто запустим Mono» ¹ , что является очень убедительным аргументом на первый взгляд, но я не согласен с некоторыми причины.

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

Мне известно, что с новым управлением Java от Oracle будущее небезопасно, но, например, IBM предоставляет JDK для многих платформ , включая Linux. Они просто не с открытым исходным кодом.

Итак, при каких условиях Mono является верной бизнес-стратегией для .NET-приложений?

¹ _{Марк Х подытожил это следующим образом : «Если заявка заключается в том, что « у меня приложение для Windows написано на .NET, оно должно работать на моно » , то нет, это недопустимая заявка - но Mono предприняла усилия по переносу таких приложений. проще «.}

Ответ Спарки получил, позвольте мне немного дополнить.

«.NET - это кроссплатформенность» - слишком неоднозначное утверждение, так как среда и среда, для которой он был изначально создан, изменились и эволюционировали.

Краткий ответ:

Базовый механизм, обеспечивающий работу .NET и его производных, Common Language Infrastructure Standard, является кроссплатформенным, и, если вы хотите, чтобы ваш код работал на нескольких платформах, вам нужно планировать использование правильных 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 subset
• 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 - соответствует профилю .NET и доступен в Linux, MacOS X, Solaris, Windows и BSD.
• .NET Micro Framework
• Mono в профиле iPhone
• Mono в профиле Android
• Моно на профиле PS3
• Mono на профиле Wii
• Профиль Moonlight (совместим с Silverlight)
• Расширенный профиль Moonlight (Silverlight + полный доступ к API .NET 4)

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

Например, API-интерфейсы Silverlight для управления браузером хоста не имеют смысла на телефоне. И шейдеры в XNA не имеют смысла на оборудовании ПК, в котором отсутствует эквивалентная поддержка.

Чем раньше вы поймете, что .NET не является решением для изоляции разработчика от базовых возможностей аппаратного обеспечения и родной платформы, тем лучше вы будете.

Начнем с того, что некоторые API и стеки доступны на нескольких платформах, например, ASP.NET можно использовать в Windows, в Linux, в Solaris, в MacOS X, потому что эти API существуют как в .NET, так и в Mono. ASP.NET недоступен на некоторых поддерживаемых Microsoft платформах, таких как XBox или Windows Phone 7, и не поддерживается ни на других платформах, которые поддерживает Mono, таких как Wii или iPhone.

Следующая информация верна только по состоянию на 21 ноября, и многое в мире моно, скорее всего, изменится.

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

Core Runtime Engine [везде]

• Поддержка Reflection.Emit [везде, кроме 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 Injection [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Generics [некоторые ограничения для PS3 и iPhone].

Языки

• C # 4 [везде]
• Компилятор C # как сервис (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [везде, кроме WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [везде, кроме WP7, CF, Xbox, MonoTouch, PS3]
• F # [везде, кроме WP7, CF, Xbox, MonoTouch, PS3]

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

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [везде]
• LINQ to SQL [везде]
• Entity Framework [везде]
• Базовый стек XML [везде]
  • XML-сериализация [везде, кроме WP7, CF, Xbox)
• LINQ to 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 [только для Windows]
• Идентификация карточного пространства [только для Windows]

GUI стеки

• Silverlight (Windows, Mac, Linux - с лунным светом)
• WPF (только для Windows)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - встроенная интеграция с Mac (только для Mac)
• MonoTouch - встроенная интеграция с iPhone (только для iPhone / iPad)
• MonoDroid - встроенная интеграция с Android (только для Android)
• API Media Center - только для Windows
• Беспорядок (Windows и Linux)

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

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

Моно библиотеки - кроссплатформенные, могут использоваться в .NET, но требуют сборки вручную

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

MonoTouch означает Mono, работающий на iPhone; MonoDroid означает Mono, работающий на Android; Порты PS3 и Wii доступны только для квалифицированных разработчиков Sony и Nintendo.

Я извиняюсь за отсутствие формальностей.

Во-первых, вам нужно провести различие между инфраструктурой общего языка (открытый стандарт) и .NET (реализация этого стандарта Microsoft). Mono является реализацией CLI и никогда не претендовал на звание «портативного .NET». Кроме того, язык C # является открытым стандартом и не привязан строго к .NET.

Я не знаю, есть ли у Microsoft какой-либо инструмент для проверки соответствия реализации, но если они это сделают, я уверен, что моно парни имеют и используют его.

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

В .NET есть ряд инструментов и расширений, например, Code Contracts. Они не всегда полностью реализованы в моно. (В настоящее время, я думаю, есть частичный валидатор контракта для Требует контрактов). В любом случае, они обычно не используются в приложениях .NET, но если их популярность возрастет, то и скорость, с которой они будут реализованы в моно, также возрастет.

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

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

Для предприятий, которые не хотят зависеть от Open Source - моно может быть переоформлено. Право собственности на код, добавленный в mono, передается novell, который может лицензировать его альтернативными способами, помимо обычной лицензии LGPL (которая в любом случае имеет очень мало ограничений).

Что касается утверждения «.NET является переносимым», я думаю, что это может быть верным утверждением, если вы пишете код с нуля и знаете о проблемах переносимости инфраструктуры. Если утверждается, что «у меня есть приложение для Windows, написанное на .NET, оно должно работать на моно», то нет, это недопустимое утверждение - но Mono предприняла усилия, чтобы упростить перенос таких приложений.

Точка за точкой:

• OpenJDK и все поставщики JVM прошли официальный Sun TCK, гарантирующий правильную работу. Я не знаю, как Моно передал Microsoft TCK.
  Существует спецификация, которой соответствует Microsoft CLR. Mono - это не клон Microsoft CLR, а реализация той же спецификации. С одной стороны, есть вероятность, что это приведет к еще большей несовместимости. На практике это очень хорошо работает для моно.
• Моно тянется за релизами .NET. Какой .NET-уровень в настоящее время полностью поддерживается?
  Поскольку документация для .Net предшествует фактическому выпуску, mono фактически завершила (не бета-выпуск) поддержку .Net 4 до официального выпуска Microsoft. Кроме того, mono отлично справляется с документированием того, что не поддерживается, и у них есть несколько инструментов, которые вы можете использовать против существующего проекта, чтобы помочь вам определить места с потенциальной несовместимостью.
• Все ли элементы графического интерфейса (WinForms?) Работают правильно в Mono?
  Подавляющее большинство winforms работает просто отлично. WPF, не так много. Я слышал, что то же самое верно для Java - многие из расширенных наборов инструментов виджета / графического интерфейса не так хорошо поддерживаются на всех платформах.
• Компании могут не захотеть зависеть от фреймворков с открытым исходным кодом в качестве официального плана B.
  Если это так, то они определенно не пойдут с Java, так как это поднимает фреймворк с открытым исходным кодом еще выше в плане А.

Итак, если вы хотите создать кроссплатформенное приложение прямо сейчас , нет ничего плохого в том, чтобы начать с mono с самого начала и использовать его в качестве своей платформы. Вы можете даже развернуть моно в Windows, если хотите.

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

Другими словами: да. .Net, если кроссплатформенный во всех отношениях, что имеет значение для вашего вопроса. Нет, mono не просто запустит каждую .Net программу из коробки, но ваш вопрос в контексте нового проекта. Не нужно много работать, чтобы не создавать новые проекты и избежать проблем с совместимостью, особенно если вы думаете о разработке для моно, а не для .Net.

Но больше всего я думаю, что это неправильный вопрос. Если вы не создаете новую команду разработчиков с нуля, вы начинаете с программистов, имеющих опыт в той или иной области. Ваши лучшие результаты будут достигнуты благодаря тому, что ваши программисты уже знают. Каким бы важным не показалось создание кроссплатформенного приложения, если у вас есть команда, полная программистов .Net с небольшим опытом работы с Java, вы вряд ли уволите их или заставите их всех изучать Java для вашего следующего проекта. Если у вас есть команда, полная программистов на Java, вы не будете просить их изучать .Net для проекта только для Windows. Любой из них будет чокнутым.

Я работал с Mono, и я бы сказал, что он настолько хорош, насколько это возможно с альтернативной платформой с открытым исходным кодом, которая напрямую не поддерживается Microsoft. Если вам удобнее использовать альтернативную платформу с открытым исходным кодом, такую ​​как Clojure или Scala, вам, вероятно, будет удобно использовать Mono.

Уровень .NET, поддерживаемый Mono, всегда можно найти на странице Mono Roadmap .

Все элементы графического интерфейса работают? Насколько я знаю, они делают, хотя я не исчерпывающе попробовал каждый элемент.

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

В качестве цели вселенная .NET / mono движется очень быстро .

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

Хотя постоянное улучшение фреймворка приветствуется, это также проблематично, если вы хотите совместимости между несколькими платформами. Платформы с долгосрочной поддержкой, такие как Red Hat Enterprise Linux, движутся крайне медленно с точки зрения внедрения новых технологий, и в любой момент в платформе Mono произойдут значительные улучшения, которые произошли в течение последних нескольких месяцев. Поэтому, если вы хотите запустить материал, который создают классные ребята, вам придется скомпилировать Mono с нуля и управлять своими собственными патчами и обновлениями. Это не круто.

Ява, с другой стороны, застойна, как детский бассейн. Особенно теперь, когда она принадлежит компании, которая просто хотела 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, б) решение основных проблем с лицензированием прошлых лет, и в) поддержка со стороны Nokia, который продает действительно очень популярные телефоны.

Mono - это не 1: 1 порт .net от Microsoft. Существуют технологии, которые Mono просто не будет внедрять или не планирует делать это (например, Workflow Foundation или WPF ), в то время как с другой стороны у них есть свои собственные технологии, которых нет у Microsoft .NET, например SIMD Extensions. ,

Краткий ответ: Mono и Microsoft .NET основаны на одной и той же основе - CIL и BCL - но это отдельные проекты.

Небольшой комментарий к высказываниям в оригинальном посте. Я буду утверждать, что TCK остается теоретическим инструментом, позволяющим Oracle утверждать, что Java является открытым стандартом. Потому что, если вы заметили, Apache Harmony уже несколько лет безуспешно пытается получить сертификат «Java». Понятно, что Oracle на самом деле не заинтересован в реализации с открытым исходным кодом, кроме той, с которой они связаны, и более или менее контролируемой (OpenJDK), которая, между прочим. так же, как Mono, не является полным (то есть не поддерживает Java Web Start) и не содержит некоторых оптимизаций, доступных в реализации HotSpot с закрытым исходным кодом.

Так что, возможно, по состоянию на 2010 год; (большая часть) Java является открытым исходным кодом, но не открытым стандартом, в то время как (большая часть) .NET является не открытым исходным кодом, а открытым стандартом. Конечно, есть исключения, DLR, IronPython, IronRuby и F # на самом деле с открытым исходным кодом. Mono интересен тем, что предоставляет лучшее из обоих миров - реализацию открытых стандартов с открытым исходным кодом.

Оставляя все технические детали в стороне, очень важная часть имеет место при написании кода.

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

Тем не менее, для нового проекта (или проекта, который вы можете легко реорганизовать), выбор .Net / Mono в качестве потенциально переносимой среды выполнения имеет смысл, но вы избавляете себя от множества хлопот, тестируя код на Mono очень рано, даже если проект имеет только небольшое изменение собирается мультиплатформенность. Если вы используете сервер непрерывной интеграции, это может быть так же просто, как настроить узел сборки Mono. Многие проблемы могут быть решены в процессе разработки, просто создав из этого привычку (например, создание строк пути), и огромный кусок вашего кода может быть переносимым и тестироваться модульно на Mono, просто используя разумные практики и немного продуманного подхода. Остальная часть (т.е. неудачные модульные тесты) затем зависит от платформы (например, код, использующий PInvoke), но должна быть достаточно инкапсулирована, чтобы иметь возможность обеспечить альтернативную реализацию для целевой платформы.

Конечно, использование библиотеки, недоступной (.Net) или совместимой (третьей стороной) в Mono, исключает все это, но в моей области это еще не видно. Это стратегия, которую мы на самом деле используем на работе, и при ее применении я не боюсь утверждать, что .Net + Mono является кроссплатформенным.

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

Однако, хотя он может работать, если вы используете вызов API, который не реализован в моно, он не будет работать, и единственными решениями будут либо переписать ваше приложение, придерживаться Windows или написать дополнительные вещи в моно.