Mono se usa con frecuencia para decir "Sí, .NET es multiplataforma". ¿Cuán válido es ese reclamo? [cerrado]

En ¿Qué elegirías para tu proyecto entre .NET y Java en este momento? Digo que consideraría el "¿Siempre implementará en Windows?" la decisión técnica más importante para hacer un proyecto web por adelantado, y si la respuesta es "no", recomendaría Java en lugar de .NET.

Un contraargumento muy común es que "si alguna vez queremos ejecutar Linux / OS X / Lo que sea, simplemente ejecutaremos Mono" ¹ , que es un argumento muy convincente en la superficie, pero no estoy de acuerdo por varios razones.

• OpenJDK y todos los JVM suministrados por el proveedor han pasado el Sun TCK oficial para garantizar que las cosas funcionen correctamente. No tengo conocimiento de que Mono pase un TCK de Microsoft.
• Mono rastrea los lanzamientos de .NET. ¿Qué nivel .NET es actualmente totalmente compatible?
• ¿Todos los elementos de la GUI (WinForms?) Funcionan correctamente en Mono?
• Es posible que las empresas no quieran depender de los marcos de código abierto como el plan oficial B.

Soy consciente de que con el nuevo gobierno de Java de Oracle, el futuro no es seguro, pero, por ejemplo, IBM proporciona JDK para muchas plataformas , incluida Linux. Simplemente no son de código abierto.

Entonces, ¿en qué circunstancias Mono es una estrategia comercial válida para aplicaciones .NET?

¹ _{Mark H lo resumió como : "Si el reclamo es que " tengo una aplicación de Windows escrita en .NET, debería ejecutarse en mono " , entonces no, no es un reclamo válido, pero Mono ha hecho esfuerzos para portar dichas aplicaciones más simple ".}

La respuesta de Sparkie lo consiguió, déjame complementar un poco.

".NET es multiplataforma" es una declaración demasiado ambigua, ya que tanto el marco como el mundo para el que se creó originalmente han cambiado y evolucionado.

La respuesta corta es:

El motor subyacente que impulsa .NET y sus derivados, el Common Language Infrastructure Standard, es multiplataforma y, como si quisiera que su código vaya a múltiples plataformas, debe planear el uso de las API correctas en la plataforma correcta para entregar La mejor experiencia en cada plataforma.

La familia CLI no ha probado el enfoque "Escribir una vez, ejecutar en cualquier lugar", ya que las diferencias entre un teléfono y una unidad central son demasiado grandes. En cambio, ha surgido un universo de características de API y tiempo de ejecución que son específicas de la plataforma para brindar a los desarrolladores las herramientas adecuadas para crear grandes experiencias en cada plataforma.

Piénselo: los programadores ya no se dirigen a PC con Windows o servidores Unix. El mundo, ahora más que nunca, está rodeado de plataformas fascinantes, desde PC hasta consolas de juegos, teléfonos potentes, decodificadores, grandes servidores y grupos distribuidos de máquinas. Un ajuste único en todas las plataformas simplemente se sentiría hinchado en dispositivos pequeños y se sentiría con poca potencia en sistemas grandes .

El producto .NET Framework de Microsoft no es multiplataforma, solo se ejecuta en Windows. Existen variaciones de .NET Framework de Microsoft que se ejecutan en otros sistemas como Windows Phone 7, XBox360 y navegadores a través de Silverlight, pero todos son perfiles ligeramente diferentes.

Hoy puede dirigirse a todos los principales sistemas operativos, teléfonos, dispositivos móviles, sistemas integrados y servidores con tecnologías basadas en .NET. Aquí hay una lista que muestra qué implementación de CLI usaría en cada caso (esta lista no es exhaustiva, pero debería cubrir el 99% de los casos):

• Computadoras PC basadas en x86 y x86-64:
  • ejecutando Windows -> Normalmente ejecuta .NET o Silverlight pero también puede usar Mono completo aquí.
  • ejecutando Linux, BSD o Solaris -> Ejecutas Mono o Silverlight completo
  • ejecutando MacOS X -> Ejecutas Full Mono o Silverlight
  • ejecutando Android -> Ejecutas el subconjunto Mono / Android
• Computadoras ARM:
  • Ejecutando Windows Phone 7: ejecuta Compact Framework 2010
  • Ejecutando Windows 6.5 y versiones anteriores: ejecutas el antiguo Compact Framework
  • Dispositivos Android: ejecutas Mono / Android
• Computadoras PowerPC:
  • Usted ejecuta Mono completo para sistemas operativos Linux, BSD o Unix completos
  • Ejecutas Mono integrado para PS3, Wii u otros sistemas integrados.
  • En XBox360, ejecuta CompactFramework
• Computadoras S390, S390x, Itanium, SPARC:
  • Ejecutas Full Mono
• Otros sistemas operativos integrados:
  • Ejecutas .NET MicroFramework o Mono con el perfil móvil.

Dependiendo de sus necesidades, lo anterior puede ser suficiente o no. Difícilmente obtendrá el mismo código fuente para ejecutar en todas partes. Por ejemplo, el código XNA no se ejecutará en todos los escritorios, mientras que el software .NET Desktop no se ejecutará en XNA o en el teléfono. Por lo general, debe realizar cambios en su código para ejecutarse en otros perfiles de .NET Framework. Estos son algunos de los perfiles que conozco:

• Perfil .NET 4.0
• Perfil de Silverlight
• Perfil de Windows Phone 7
• Perfil XBox360
• Perfil mono núcleo: sigue el perfil .NET y está disponible en Linux, MacOS X, Solaris, Windows y BSD.
• .NET Micro Framework
• Mono en el perfil de iPhone
• Mono en el perfil de Android
• Mono en el perfil de PS3
• Mono en el perfil de Wii
• Perfil de luz de luna (compatible con Silverlight)
• Perfil extendido Moonlight (Silverlight + acceso completo a .NET 4 API)

Entonces, cada uno de esos perfiles es en realidad un poco diferente, y esto no es algo malo. Cada perfil está diseñado para adaptarse a su plataforma de host y exponer las API que tienen sentido y eliminar las que no tienen sentido.

Por ejemplo, las API de Silverlight para controlar el navegador host no tienen sentido en el teléfono. Y los sombreadores en XNA no tienen sentido en el hardware de PC que carece del soporte equivalente para él.

Cuanto antes se dé cuenta de que .NET no es una solución para aislar al desarrollador de las capacidades subyacentes del hardware y la plataforma nativa, mejor estará.

Dicho esto, algunas API y pilas están disponibles en varias plataformas, por ejemplo, ASP.NET se puede usar en Windows, Linux, Solaris y MacOS X porque esas API existen tanto en .NET como en Mono. ASP.NET no está disponible en algunas de las plataformas compatibles de Microsoft como XBox o Windows Phone 7 y tampoco es compatible con otras plataformas que Mono admite como Wii o iPhone.

La siguiente información solo es correcta a partir del 21 de noviembre, y muchas cosas en el mundo Mono probablemente cambiarán.

Los mismos principios se pueden aplicar a otras pilas, una lista completa requeriría una tabla adecuada, que no tengo idea de cómo presentar aquí, pero aquí hay una lista de tecnologías que podrían no estar presentes en una plataforma en particular. Puede suponer que cualquier cosa que no esté en la lista aquí está disponible (no dude en enviarme ediciones para las cosas que me perdí)

Core Runtime Engine [en todas partes]

• Reflection.Emit Support [en todas partes, excepto WP7, CF, Xbox, MonoTouch, PS3]
• Compatibilidad con CPU SIMD [Linux, BSD, Solaris, MacOS X; Pronto PS3, MonoTouch y MonoDroid]
• Continuaciones - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Descarga de ensamblaje [solo Windows]
• Inyección de VM [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Genéricos [algunas limitaciones en PS3 y iPhone].

Idiomas

• C # 4 [en todas partes]
• Compilador de C # como servicio (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [en todas partes, excepto WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [en todas partes, exec WP7, CF, Xbox, MonoTouch, PS3]
• F # [en todas partes, excepto WP7, CF, Xbox, MonoTouch, PS3]

Pilas de servidor

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [en todas partes]
• LINQ to SQL [en todas partes]
• Entity Framework [en todas partes]
• Pila XML principal [en todas partes]
  • Serialización XML [en todas partes, excepto WP7, CF, Xbox)
• LINQ to XML (en todas partes)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; en Linux, MacOS y Solaris requiere RabbitMQ]
• .NET 1 Enterprise Services [solo Windows]
• WCF [completo en Windows; pequeño subconjunto en Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
• Flujo de trabajo de Windows [solo Windows]
• Identidad de espacio de tarjeta [solo Windows]

Pilas GUI

• Silverlight (Windows, Mac, Linux - con Moonlight)
• WPF (solo Windows)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - Integración nativa de Mac (solo Mac)
• MonoTouch - Integración nativa de iPhone (solo iPhone / iPad)
• MonoDroid - Integración nativa de Android (solo Android)
• API de Media Center: solo Windows
• Desorden (Windows y Linux)

Bibliotecas Gráficas

• GDI + (Windows, Linux, BSD, MacOS)
• Cuarzo (MacOS X, iPhone, iPad)
• El Cairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Bibliotecas mono: multiplataforma, se pueden usar en .NET pero requieren una creación manual

• Compilador C # 4 como servicio
• Cecil - CIL Manipulación, flujo de trabajo, instrumentación de CIL, Linkers
• Bibliotecas RelaxNG
• Proveedores de bases de datos Mono.Data. *
• System.Xaml completo (para usar en configuraciones donde .NET no ofrece la pila)

MonoTouch significa Mono ejecutándose en iPhone; MonoDroid significa Mono ejecutándose en Android; Los puertos PS3 y Wii solo están disponibles para los desarrolladores calificados de Sony y Nintendo.

Pido disculpas por la falta de formalidad.

Primero, debe hacer una distinción entre la infraestructura de lenguaje común (el estándar abierto) y .NET (la implementación de Microsoft de ese estándar). Mono es una implementación de la CLI, y nunca ha afirmado ser un ".NET portátil". Además, el lenguaje C # es un estándar abierto y no está estrictamente vinculado a .NET.

No sé si Microsoft tiene alguna herramienta para validar que una implementación es compatible, pero si la tienen, estoy bastante seguro de que los chicos mono la tienen y la usan.

Mono está detrás de .Net, pero apenas. Mono puede ejecutar código C # 4.0 (versión actual .NET). Además, Microsoft recientemente ha hecho que todo el código DLR y las bibliotecas sean de código abierto (bajo la licencia Apache 2.0), lo que ha permitido que mono use idiomas como IronPython, IronRuby, y F # se hizo de código abierto solo la semana pasada. Además, Microsoft publica regularmente CTP de las próximas características en .NET, lo que permite a los desarrolladores mono mantenerse al día con las versiones de lanzamiento actuales.

Hay una serie de herramientas y extensiones en .NET, por ejemplo, contratos de código. Estos no siempre se implementan completamente en mono. (En la actualidad, creo que hay un validador de contrato parcial para los contratos Requiere). De todos modos, estos no se usan comúnmente en aplicaciones .NET, pero si su popularidad aumentara, también lo haría la velocidad a la que se implementan en mono.

WinForms no son (totalmente) portátiles. Son específicos de .NET y no forman parte de la CLI. La CLI no especifica ningún conjunto de widgets en particular. Sin embargo, hay conjuntos de widgets multiplataforma (GTK # y Silverlight). Si estuviera escribiendo una aplicación desde cero con la portabilidad en mente, usaría una de estas en lugar de Winforms / WPF. Además, mono proporciona un envoltorio delgado para la API Winforms, que permite que las aplicaciones winforms existentes se transfieran más fácilmente a GTK # (sin reescribir por completo).

Mono proporciona una herramienta, el Analizador de Migración Mono (MoMA), que puede tomar una aplicación .Net existente y contarle sobre su portabilidad. (p. ej., identificar bibliotecas no portables que se utilizan, P / Invocaciones, etc.).

Para las empresas que no quieren depender de Open Source, Mono puede volver a licenciarse. La propiedad del código agregado a mono se transfiere a novell, que puede licenciarlo de formas alternativas que no sean la licencia LGPL habitual (que de todos modos tiene muy pocas restricciones).

En cuanto a la afirmación ".NET es portátil", creo que esta puede ser una afirmación válida si está escribiendo código desde cero y está al tanto de los problemas de portabilidad con el marco. Si el reclamo es que "Tengo una aplicación de Windows escrita en .NET, debería ejecutarse en mono", entonces no, no es un reclamo válido, pero Mono ha hecho esfuerzos para simplificar la transferencia de tales aplicaciones.

Punto por punto:

• OpenJDK y todos los JVM suministrados por el proveedor han pasado el Sun TCK oficial para garantizar que las cosas funcionen correctamente. No tengo conocimiento de que Mono pase un TCK de Microsoft.
  Hay una especificación a la que se ajusta el CLR de Microsoft. Mono no es un clon del CLR de Microsoft, sino más bien una implementación de esa misma especificación. Por un lado, existe la posibilidad de que esto resulte en una incompatibilidad aún mayor. En la práctica, esto ha funcionado muy bien para mono.
• Mono rastrea los lanzamientos de .NET. ¿Qué nivel .NET es totalmente compatible actualmente?
  Debido a que la documentación para .Net precede a la versión real, Mono en realidad había completado (no una versión beta) soporte para .Net 4 antes de la versión oficial de Microsoft. Además, mono hace un muy buen trabajo al documentar las cosas que no son compatibles, y tienen algunas herramientas que puede ejecutar contra proyectos existentes para ayudarlo a detectar lugares con potencial de incompatibilidad.
• ¿Todos los elementos de la GUI (WinForms?) Funcionan correctamente en Mono?
  La gran mayoría de winforms funciona bien. WPF, no tanto. He oído que lo mismo es cierto para Java: muchos de los kits avanzados de herramientas de widgets / gui no son tan compatibles en todas las plataformas.
• Es posible que las empresas no quieran depender de los marcos de código abierto como el plan oficial B.
  Si ese es el caso, definitivamente no irán con Java, ya que eso eleva aún más el marco de código abierto en el plan A.

En resumen, si desea crear una aplicación multiplataforma en este momento , no hay nada de malo en comenzar con mono desde el principio y usarlo como marco. Incluso puede implementar mono en Windows si lo desea.

Por otro lado, si está buscando construir una aplicación de Windows hoy que cree que podría necesitar ser multiplataforma en algún momento desconocido en el futuro, probablemente quiera usar los widgets y herramientas nativos de Windows. .Net hace un trabajo mucho mejor aquí que Java, y mono es un retroceso perfectamente aceptable en este escenario.

En otras palabras: sí, .Net si es multiplataforma en todos los aspectos importantes para su pregunta. No, mono no solo ejecutará todos los programas .Net listos para usar, sino que su pregunta está en el contexto de un nuevo proyecto. No lleva mucho trabajo mantener los nuevos proyectos fuera de problemas y evitar problemas de compatibilidad, especialmente si piensa en términos de desarrollo para mono en lugar de desarrollo para .Net.

Sin embargo, sobre todo, creo que esta es la pregunta equivocada en primer lugar. A menos que esté construyendo un nuevo equipo de desarrollo desde cero, está comenzando con programadores que tienen experiencia en un área u otra. Sus mejores resultados se lograrán siguiendo lo que sus programadores ya saben. Por muy importante que parezca crear una aplicación multiplataforma, si tiene un equipo lleno de programadores .Net con poca experiencia en Java, es poco probable que los dispare o haga que todos aprendan Java para su próximo proyecto. Si tiene un equipo lleno de programadores de Java, no les pedirá que aprendan .Net para un proyecto exclusivo de Windows. Cualquiera de esos sería una locura.

He trabajado con Mono, y diría que es lo mejor que puede obtener con una plataforma alternativa que es de código abierto y que Microsoft no admite directamente. Si puede sentirse cómodo usando una plataforma alternativa de código abierto como Clojure o Scala, probablemente podría sentirse cómodo usando Mono.

El nivel de .NET admitido por Mono siempre se puede encontrar en la página Mapa de ruta de Mono .

¿Funcionan todos los elementos de la GUI? Hasta donde yo sé, lo hacen, aunque no he probado exhaustivamente cada elemento.

¿Mono es idéntico a .NET? No. Sospecho que habrá ajustes menores (y quizás importantes) necesarios aquí y allá. Por el momento, no puede ejecutar Entity Framework con él, por ejemplo.

Como objetivo, el universo .NET / mono se mueve muy rápido .

Cada pocos años, Microsoft presenta algunos cambios e innovaciones convincentes con respecto al lenguaje, el tiempo de ejecución y la infraestructura que rodea a .NET. Por ejemplo: Genéricos, LINQ, DLR, Entity Framework: con cada nueva revisión de Visual Studio, generalmente hay un aumento bastante significativo en el conjunto de características y la utilidad del marco al que apunta.

Si bien la mejora constante en el marco es bienvenida, también es problemática si desea compatibilidad en múltiples plataformas. Las plataformas de soporte a largo plazo como Red Hat Enterprise Linux se mueven muy lentamente con respecto a la adopción de nueva tecnología, y en cualquier punto dado, habrá mejoras significativas en la plataforma Mono que se han producido en los últimos meses. Entonces, si desea ejecutar las cosas que los niños geniales están construyendo, tendrá que compilar Mono desde cero y administrar sus propios parches y actualizaciones. Eso no es cool.

Java, por otro lado, está tan estancado como un grupo de niños. Especialmente ahora que es propiedad de una compañía que solo quería Java para las demandas de patentes, puede estar bastante seguro de que no habrá cambios detectables en el idioma o el tiempo de ejecución en el futuro previsible. Java es una plataforma tan estable como FORTRAN. Eso no es tan bueno si esperaba algún tipo de mejoras, pero no es tan malo si está tratando de implementar una aplicación empresarial.

Desde la perspectiva del usuario, Mono apesta a hacer que las aplicaciones Windows .NET sean compatibles con Linux. Si realmente intenta ejecutar cualquier aplicación de Windows escrita de manera decente en Mono, no funcionaría.

Desde la perspectiva de un empaquetador (solía hacer un poco de trabajo en PortableApps), .NET puede ser tanto una bendición como una maldición. Si solo está en Windows, .NET hace que la implementación sea mucho más fácil porque más bibliotecas significan menos cosas dependientes del sistema (más notablemente entre versiones de Windows, creo) pero también es extremadamente confuso incluso en Windows porque las versiones de .NET no son al revés -compatible o compatible hacia adelante. Tienes que descargar diferentes versiones de .NET para diferentes programas.

Dicho esto, Mono es un buen punto de partida para hacer que los programas de C # sean multiplataforma. Sin embargo, no empaquete el programa con el último WINE y llámelo listo. Mira a dónde llevó eso a Picasa.

Al igual que con la estabilidad política de los dos idiomas / plataformas, RMS probablemente comenzaría a hablar sobre cómo Mono está encabezado por Novell, cuya luna de miel con Microsoft es bastante notoria. Ambas plataformas pueden considerarse políticamente inestables en este momento.

Si realmente quiere una plataforma multiplataforma fácil, el camino probado y verdadero es QT, que es bastante estable desde el punto de vista político en este momento, es a) LGPL'd, b) hecho con sus principales problemas de licencias años atrás, yc) respaldado por Nokia, que vende teléfonos realmente muy populares.

Mono no es un puerto 1: 1 de .net de Microsoft. Hay tecnologías que Mono simplemente no implementará o no tiene planes de hacerlo (por ejemplo, Workflow Foundation o WPF ) mientras que, por otro lado, tienen algunas tecnologías propias que Microsoft .NET no hace, por ejemplo, Extensiones SIMD .

Respuesta corta: Mono y Microsoft .NET se basan en la misma base subyacente, CIL y BCL, pero son proyectos separados.

Pequeño comentario a las declaraciones en la publicación original. Argumentaré que el TCK sigue siendo una herramienta teórica que permite a Oracle afirmar que Java es un estándar abierto. Porque si te das cuenta, Apache Harmony ha estado tratando de obtener la certificación como "Java" durante varios años, sin éxito. Está claro que Oracle realmente no está interesado en una implementación de código abierto aparte de la que está afiliada y con más o menos control (OpenJDK), que por cierto. al igual que Mono, no está completo (es decir, no es compatible con Java Web Start) y le faltan algunas optimizaciones disponibles en la implementación de HotSpot de código cerrado.

Podría decirse que a partir de 2010; (la mayoría de) Java es de código abierto pero no es un estándar abierto, mientras que (la mayoría de) .NET no es de código abierto sino un estándar abierto. Por supuesto, hay excepciones, DLR, IronPython, IronRuby y F # en realidad son de código abierto. Mono es interesante porque proporciona lo mejor de ambos mundos, implementaciones de código abierto de estándares abiertos.

Dejando a un lado todos los tecnicismos, una parte muy importante ocurre cuando se escribe el código.

Al igual que con cualquier tecnología multiplataforma (ya sea Java, Python, Ruby ...), si el código no está escrito teniendo en cuenta la portabilidad, debe asumir que hay básicamente cero posibilidades de que el código se ejecute correctamente (incluso si tal posibilidad es en realidad mucho, mucho más alto), ya que el extraño mal comportamiento podría ser bastante crítico. Leer: no tome el ensamblaje aleatorio y ejecútelo en Mono.

Sin embargo, para un nuevo proyecto (o uno que puede refactorizar fácilmente), elegir .Net / Mono como un tiempo de ejecución potencialmente portátil tiene sentido, pero se ahorra muchas molestias al probar su código en Mono muy pronto, incluso si el proyecto tiene solo un ligero cambio de multiplataforma. Si utiliza un servidor de integración continua, esto puede ser tan simple como configurar un nodo de compilación Mono. Se pueden resolver muchos problemas durante el desarrollo, simplemente haciendo un hábito (como construir cadenas de ruta) y una gran parte de su código puede ser portátil y probado en Mono con solo usar prácticas sensatas y un poco de previsión. El resto (es decir, las pruebas de unidades fallidas) es específico de la plataforma (como el código que usa PInvoke), pero debe encapsularse lo suficiente como para poder proporcionar una implementación alternativa por plataforma objetivo.

Por supuesto, el uso de una biblioteca no disponible (.Net) o compatible (de terceros) en Mono excluye todo esto, pero en mi campo esto aún no se ha visto. Esa es la estrategia que realmente utilizamos en el trabajo, y al aplicarla no tengo miedo de afirmar que .Net + Mono es multiplataforma.

Varía es la respuesta honesta. He visto pequeñas cosas del servidor web movidas de IIS a Apache, ejecutándose en mono sin casi ninguna dificultad. He ejecutado aplicaciones Windows .Net sin cambios utilizando Win Forms en Linux con éxito.

Sin embargo, si bien puede funcionar, si está utilizando una llamada API que no está implementada en mono, entonces no funcionará, y las únicas soluciones son reescribir su aplicación, quedarse con Windows o escribir las cosas adicionales en mono.