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

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

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

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

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

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


1 Mark H суммировал его как :« Если утверждение таково, что », у меня есть приложение Windows, написанное на .NET, оно должно run on mono ", то нет, это не действительное утверждение, но Mono прилагает усилия, чтобы упростить перенос таких приложений.

168 голосов | спросил user1249 20 62010vEurope/Moscow11bEurope/MoscowSat, 20 Nov 2010 20:11:48 +0300 2010, 20:11:48

10 ответов


194

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

Подлинный движок, который поддерживает .NET и его производные, Common Language Infrastructure Standard, является кросс-платформенным и, как если бы вы хотели, чтобы ваш код переходил на несколько платформ, вам нужно планировать использование правильных API-интерфейсов на правой платформе , чтобы обеспечить лучший опыт на каждой платформе.

Семейство CLI не пробовало подход «Write Once, Run Anywhere», поскольку различия с телефоном на мейнфрейме слишком велики. Вместо этого появилась универсальность 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:
    • Вы выполняете полную монографию
  • Другие встроенные операционные системы:
    • Вы запускаете .NET MicroFramework или Mono с мобильным профилем.

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

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

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

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

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

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

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

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

Core Runtime Engine [везде]

  • Reflection.Emit Support [везде, кроме WP7, CF, Xbox, MonoTouch, PS3]
  • Поддержка CPU SIMD [Linux, BSD, Solaris, MacOS X; Скоро PS3, MonoTouch и MonoDroid]
  • Continuations - 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 [везде, execpt WP7, CF, Xbox, MonoTouch, PS3]
  • IronPython [везде, execpt WP7, CF, Xbox, MonoTouch, PS3]
  • F # [везде, execpt 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 - с Moonlight)
  • 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
  • Clutter (Windows и Linux)

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

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

Mono Libraries - Cross Platform, может использоваться в .NET, но требует создания вручную

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

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

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

ответил miguel.de.icaza 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 23:38:07 +0300 2010, 23:38:07
114

Во-первых, вам нужно провести различие между Инфраструктурой общего языка (Открытый стандарт) и .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. Кроме того, mono предоставляет тонкую оболочку для API Winforms, которая позволяет более легко переносить существующие приложения winforms в GTK # (без полной перезаписи).

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

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

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

ответил Mark H 20 62010vEurope/Moscow11bEurope/MoscowSat, 20 Nov 2010 20:51:51 +0300 2010, 20:51:51
14

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

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

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

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

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

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

ответил Joel Coehoorn 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 04:13:30 +0300 2010, 04:13:30
11

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

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

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

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

ответил Robert Harvey 20 62010vEurope/Moscow11bEurope/MoscowSat, 20 Nov 2010 20:47:02 +0300 2010, 20:47:02
9

В качестве цели, .NET /mono universe перемещается очень быстро .

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

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

Java, с другой стороны, столь же застенчива, как и детский бассейн. Особенно сейчас, когда она принадлежит компании, которая просто хотела Java для патентных исков, вы можете быть достаточно уверены, что не может быть обнаружено изменений в языке или времени исполнения в обозримом будущем. Java является такой же стабильной платформой, как FORTRAN. Это не так хорошо, если вы надеялись на какие-то улучшения, но не так уж плохо, если вы пытаетесь развернуть корпоративное приложение.

ответил tylerl 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 06:59:19 +0300 2010, 06:59:19
7

С точки зрения пользователя, 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, которая продает действительно действительно популярные телефоны.

ответил digitxp 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 04:01:04 +0300 2010, 04:01:04
4

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

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

ответил Michael Stum 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 04:13:31 +0300 2010, 04:13:31
2

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

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

ответил Casper Bang 22 12010vEurope/Moscow11bEurope/MoscowMon, 22 Nov 2010 11:46:38 +0300 2010, 11:46:38
1

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

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

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

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

ответил Lloeki 21 72010vEurope/Moscow11bEurope/MoscowSun, 21 Nov 2010 13:15:26 +0300 2010, 13:15:26
0

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

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

ответил Michael Shaw 20 62010vEurope/Moscow11bEurope/MoscowSat, 20 Nov 2010 20:52:40 +0300 2010, 20:52:40

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132