¿Mono está listo para el prime time? [cerrado]

Tiene una cobertura bastante extensa hasta.NET 4.0 e incluso incluye algunas características de las API. NET 4.5, pero hay algunas áreas que hemos elegido no implementar debido a que las API están en desuso, se crean nuevas alternativas o el alcance es demasiado grande. Las siguientes API no están disponibles en Mono:

• Fundación Presentación de Windows
• Windows Workflow Foundation (ninguna de las dos versiones)
• Entity Framework
• Los "complementos" WSE1/WSE2 a la pila de servicios web estándar

Además, nuestra implementación de WCF se limita a lo que Silverlight admite.

La forma más fácil de comprobar su proyecto específico es ejecutar el Mono Migration Analyzer (MoMA). El beneficio es que notificará al equipo Mono de problemas que le impedirán usar Mono (si los hay), lo que les permite priorizar su trabajo.

Recientemente ejecuté el MoMA en SubSonic y solo encontré un problema: un extraño uso de tipos Nullables. Eso es una gran base de código, por lo que la cobertura allí fue bastante impresionante.

Mono está en uso activo en varios productos comerciales y de código abierto . Está en uso en algunas aplicaciones grandes, como Wikipedia y el Mozilla Developer Center , y se ha utilizado en aplicaciones incrustadas como los reproductores de MP3 Sansa y alimenta miles de juegos publicados.

A nivel de lenguaje, el compilador Mono es totalmente compatible con el lenguaje C # 5.0 especificación.

En el lado del escritorio, Mono funciona muy bien si te comprometes a usar GTK#. ventana.La implementación de formularios sigue siendo un poco defectuosa (por ejemplo, TrayIcon no funciona), pero ha recorrido un largo camino. Además, GTK # es un mejor kit de herramientas que Windows Forms como es.

En el lado web, Mono ha implementado suficiente de ASP.NET para ejecutar la mayoría de los sitios perfectamente. La dificultad aquí es encontrar un host que tenga mod_mono instalado en apache, o hacerlo usted mismo si tiene acceso al shell host.

De cualquier manera, Mono es grande y estable.

Cosas clave a recordar al crear un programa multiplataforma:

• Use GTK# en lugar de Windows.Formularios
• Asegúrese de guardar correctamente sus nombres de archivo
• Use Path.Separator en lugar de codificar "\", también use Environment.NewLine en lugar de "\n".
• No use llamadas P/Invocadas a la API Win32.
• No utilice el Registro de Windows.

Yo personalmente uso Mono en un env de prime-time. Corro servidores mono que se ocupan de giga-bytes de tareas relacionadas con el procesamiento de datos udp/tcp y no podría estar más feliz.

Hay peculiaridades, y una de las cosas más molestas es que no puedes simplemente "construir" tus archivos msbuild debido al estado actual de Mono:

• MonoDevelop (el IDE) tiene cierto soporte parcial para msbuild, pero básicamente bork en cualquier configuración" REAL " más allá de un simple hello-world (tareas de compilación personalizadas, dinámica "propiedades" como $(SolutionDir), configuración real para nombrar algunos callejones sin salida)
• xbuild que DEBERÍA haber sido el mono-supplied-msbuild-fully-compatible-build-system es aún más horrible, por lo que construir desde la línea de comandos es en realidad una experiencia peor que usar la GUI, que es un estado muy "poco ortodoxo" de la unión para entornos Linux...

Una vez / Durante la construcción de sus cosas, es posible que vea algunos espacios salvajes incluso para el código que DEBERÍA ser soportado como:

• el compilador se borked en ciertas construcciones
• y ciertas clases. NET más avanzadas / nuevas lanzándote basura no esperada (XLinq ¿alguien?)
• algunas "características" de tiempo de ejecución inmaduras (límite de montón DE 3 GB EN x64... ¡WTF!)

pero heaving dijo que, en términos generales, las cosas comienzan a funcionar muy rápidamente, y las soluciones/soluciones alternativas son abundantes .

Una vez que hayas superado esos obstáculos iniciales, mi experiencia es que ROCAS, y sigue mejorando con cada iteración.

He tenido servidores funcionando con mono, procesando 300 GB de datos por día, con toneladas de p/invokes y, en general, haciendo mucho trabajo y manteniéndome despierto durante 5-6 meses, incluso con el mono "bleeding edge".

Espero que esto ayude.

Las recomendaciones para la respuesta aceptada están un poco desactualizadas ahora.

• La implementación de windows forms es bastante buena ahora. (Véase Paint-Mono para un puerto de Paint.net que es una aplicación de Windows forms bastante involucrada. Todo lo que se necesitaba era una capa de emulación para algunas de las llamadas al sistema P-Invoke y no soportadas).
• Ruta.Combinar, así como el camino.Seperator para unir rutas y nombres de archivo.
• El Registro de Windows está bien, siempre y cuando solo usarlo para almacenar y recuperar datos de sus aplicaciones (es decir, no puede obtener ninguna información sobre Windows de él, ya que es básicamente un registro para aplicaciones Mono).

Si desea utilizar WPF you'rr out of luck Mono actualmente no tiene planes de implementarlo.

Http://www.mono-project.com/WPF

Bueno, mono es genial, pero por lo que puedo ver, es inestable. Funciona, pero falla cuando le das al proceso mono un trabajo serio que hacer.

TL;DR - No use mono si :

• usar AppDomains (Carga de ensamblaje\Descarga) en entornos multihilo
• No puede sostener el modelo 'let-it-fail'
• Experimenta eventos ocasionales de carga pesada durante la ejecución del proceso

Entonces, los hechos.

Utilizamos mono-2.6.7 (. net v 3.5) en RHEL5, Ubuntu, y, para mi punto de vista, es la versión más estable construida por Novell. Tiene un problema con la descarga de AppDomains (segfaults), sin embargo, falla muy raro y esto, de lejos, es aceptable (por nosotros).

Bien. Pero si desea utilizar las características de. net 4.0, tiene que cambiar a las versiones 2.10.x, ó 3.x, y ahí es donde comienzan los problemas.

En comparación con 2.6.7, las nuevas versiones son simplemente inaceptables para ser utilizadas. Escribí una aplicación de prueba de esfuerzo simple para probar instalaciones mono.

Está aquí, con instrucciones de uso : https://github.com/head-thrash/stress_test_mono

Utiliza Subprocesos de Trabajo de Grupo de Subprocesos. Worker carga dll a AppDomain e intenta hacer algo de trabajo matemático. Parte del trabajo es de muchos hilos, algunos son simples. Casi todo el trabajo está ligado a la CPU, aunque hay algunas lecturas de archivos desde el disco.

Los resultados no son muy buenos. De hecho, para la versión 3.0.12:

• sgen GC proceso de segmentación casi inmediatamente
• mono con boehm vive más tiempo (de 2 a 5 horas), pero los segfaults eventualmente

Como se mencionó anteriormente, sgen gc simplemente no funciona (mono construido a partir de la fuente):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

En cuanto a boehm segfauls - por ejemplo (Ubuntu 13.04, mono construido desde el código fuente):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

O (RHEL5, mono se toma de rpm aquí ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5)

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

Ambos fallos están de alguna manera conectados a la lógica de AppDomains, por lo que debe mantenerse alejado de ellos en mono.

POR cierto, el programa probado trabajó 24 horas en la máquina Windows en MS.NET 4.5 env sin ningún fallo.

Así que, en conclusión, me gustaría decir - use mono con precaución. Funciona desde el primer vistazo, pero puede fallar fácilmente en cualquier momento. Te quedarías con un montón de volcados de núcleo y una gran pérdida de fe en proyectos de código abierto.

MoMA es una gran herramienta para esto, como alguien sugirió. Las mayores fuentes de incompatibilidad en estos días son las aplicaciones que DllImport (o P / Invoke) en las bibliotecas Win32. Algunos ensamblados no están implementados, pero la mayoría son solo para Windows y realmente no tendrían sentido en Linux. Creo que es bastante seguro decir que la mayoría ASP.NET las aplicaciones pueden ejecutarse en Mono con modificaciones limitadas.

(Divulgación: He contribuido a Mono en sí, así como aplicaciones escritas que se ejecutan en la parte superior.)

En muchos casos, puede tomar código existente y simplemente ejecutarlo en Mono, particularmente si está portando un ASP.NET solicitud.

En algunos casos, es posible que necesite secciones completamente nuevas de código para que funcione. Si utilizas el Sistema.Windows.Formularios, por ejemplo, la aplicación no funcionará sin modificar. Del mismo modo, si utiliza cualquier código específico de Windows (código de acceso al registro, por ejemplo). Pero creo que el peor delincuente es el código UI. Eso es particularmente malo en sistemas Macintosh.

Lo hemos estado usando para un proyecto aquí en el trabajo que necesitaba ejecutarse en Linux pero reutilizar algunas bibliotecas.NET que construimos en Managed C++. Me ha sorprendido mucho lo bien que ha funcionado. Nuestro ejecutable principal está escrito en C# y solo podemos hacer referencia a nuestros binarios administrados de C++ sin problemas. La única diferencia en el código C# entre Windows y Linux es el código del puerto serie RS232.

El único gran problema que se me ocurre ocurrió hace un mes. La compilación de Linux tenía un pérdida de memoria que no se vio en la construcción de Windows. Después de hacer un poco de depuración manual (los perfiladores básicos para Mono en Linux no ayudaron mucho), pudimos reducir el problema a un fragmento específico de código. Terminamos parcheando una solución, pero todavía necesito encontrar algo de tiempo para volver y averiguar cuál fue la causa raíz de la fuga.

¿Sabes lo bueno que es el soporte de Mono 2.0 preview para Windows Forms 2.0?

Por lo poco que he jugado con él, parecía relativamente completo y casi utilizable. Simplemente no se veía bien en algunos lugares y sigue siendo un poco golpeado o errado en general. Me sorprendió que funcionara tan bien como lo hizo con algunas de nuestras formas, aunque honestamente.

Sí, definitivamente lo es (si tienes cuidado, sin embargo) Soportamos Mono en Ra-Ajax (biblioteca Ajax encontrada en http://ra-ajax.org ) y en su mayoría no tenemos problemas en absoluto. Debe tener cuidado con algunas de las "cosas más insanas" de.Net como WSE, etc., y también probablemente algunos de sus proyectos existentes no serán 100% compatibles con Mono, pero los nuevos proyectos si los prueba durante el desarrollo serán principalmente compatibles sin problemas con Mono. Y la ganancia de apoyar Linux, etc. a través del uso de Mono es realmente genial;)

Una gran parte del secreto de soportar Mono creo que es usar las herramientas correctas desde el principio, por ejemplo, ActiveRecord, log4net, ra-ajax, etc...

Para el tipo de aplicación que estamos construyendo Mono desafortunadamente no parece listo para la producción. Quedamos impresionados con él en general, e impresionados con su rendimiento tanto en Windows como en máquinas EC2, sin embargo, nuestro programa se estrelló consistentemente con errores de recolección de basura tanto en Windows como en Linux.

El mensaje de error es: "errores fatales en GC: demasiadas secciones de montón", aquí hay un enlace a otra persona que experimenta el problema de una manera ligeramente diferente camino:

Http://bugzilla.novell.com/show_bug.cgi?id=435906

La primera pieza de código que ejecutamos en Mono fue un simple desafío de programación que habíamos desarrollado... El código carga unos 10mb de datos en algunas estructuras de datos (por ejemplo, HashSets), luego ejecuta 10 consultas contra los datos. Ejecutamos las consultas 100 veces para cronometrarlas y obtener un promedio.

El código se bloqueó alrededor de la consulta 55 en Windows. En Linux funcionó, pero tan pronto como nos movimos a un conjunto de datos más grande, se estrellaría también.

Este código es muy simple, por ejemplo, poner algunos datos en HashSets y luego consultar esos HashSets, etc., todo c# nativo, nada inseguro, sin llamadas API. En el CLR de Microsoft nunca se bloquea, y se ejecuta en grandes conjuntos de datos 1000s veces muy bien.

Uno de nuestros chicos envió un correo electrónico a Miguel e incluyó el código que causó el problema, sin respuesta todavía. :(

También parece que muchas otras personas se han encontrado con este problema sin solución - se ha sugerido una solución para recompile Mono con diferentes configuraciones de GC, pero eso solo parece aumentar el umbral antes del cual se bloquea.

Simplemente compruebe www.plasticscm.com. Todo (cliente, servidor, GUI, herramientas de combinación) está escrito en mono.

Realmente depende de los espacios de nombres y clases que esté utilizando desde.NET framework. Tenía interés en convertir uno de mis servicios de Windows para que se ejecutara en mi servidor de correo electrónico, que es Suse, pero nos encontramos con varios obstáculos difíciles con API que no se habían implementado completamente. Hay un gráfico en algún lugar del sitio web Mono que enumera todas las clases y su nivel de finalización. Si su solicitud está cubierta, entonces adelante.

Como cualquier otra aplicación, haga prototipado y pruebas antes de hacer un compromiso completo, por supuesto.

Otro problema que encontramos es el software con licencia: si hace referencia al DLL de otra persona, no puede codificar las incompatibilidades que están enterradas en ese ensamblaje.

Me imagino que entonces si usted tiene una aplicación con algunos componentes de terceros que puede ser rellenado. Dudo que muchos proveedores se desarrollarán con Mono en mente

Ejemplo: http://community.devexpress.com/forums/p/55085/185853.aspx

No, mono no está listo para un trabajo serio. Escribí algunos programas en Windows usando F# y los ejecuté en Mono. Esos programas usaban el disco, la memoria y la cpu con bastante intensidad. Vi bloqueos en bibliotecas mono (código administrado), bloqueos en código nativo y bloqueos en la máquina virtual. Cuando mono funcionaba, los programas eran al menos dos veces más lentos que en.Net en Windows y usaban mucha más memoria. Manténgase alejado de mono para el trabajo serio.