¿Mono está listo para el horario estelar? [cerrado]

¿Alguien ha usado Mono, la implementación de código abierto .NET en un proyecto grande o mediano? Me pregunto si está listo para entornos de producción del mundo real. ¿Es estable, rápido, compatible, ... suficiente para usar? ¿Se necesita mucho esfuerzo para transferir proyectos al tiempo de ejecución de Mono, o es realmente, lo suficientemente compatible como para tomar y ejecutar código ya escrito para el tiempo de ejecución de Microsoft?

Hay un par de escenarios a considerar: (a) si está portando una aplicación existente y se pregunta si Mono es lo suficientemente bueno para esta tarea; (b) está comenzando a escribir un código nuevo y desea saber si Mono es lo suficientemente maduro.

Para el primer caso, puede usar la herramienta Mono Migration Analyzer (Moma) para evaluar qué tan lejos se está ejecutando su aplicación en Mono. Si la evaluación regresa con gran éxito, debe comenzar con sus pruebas y control de calidad y prepararse para enviar.

Si su evaluación regresa con un informe que resalta las características que faltan o difieren significativamente en su semántica en Mono, deberá evaluar si el código se puede adaptar, reescribir o, en el peor de los casos, si su aplicación puede funcionar con una funcionalidad reducida.

De acuerdo con nuestras estadísticas de Moma basadas en los envíos de los usuarios (esto es de la memoria), aproximadamente el 50% de las aplicaciones funcionan de forma inmediata, aproximadamente el 25% requiere aproximadamente una semana de trabajo (refactorización, adaptación) y otro 15% requiere un compromiso serio con rehaga fragmentos de su código, y el resto simplemente no vale la pena molestarse en portarlos, ya que están increíblemente vinculados a Win32. En ese punto, ya sea que comience desde cero, o una decisión comercial impulsará el esfuerzo para hacer que su código sea portátil, pero estamos hablando de meses de trabajo (al menos de los informes que tenemos).

Si está comenzando desde cero, la situación es mucho más simple, porque solo usará las API que están presentes en Mono. Mientras permanezca con la pila compatible (que es más o menos .NET 2.0, además de todas las actualizaciones principales en 3.5, incluidas LINQ y System.Core, más cualquiera de las API de plataforma cruzada de Mono) estará bien.

De vez en cuando, puede encontrar errores en Mono o limitaciones, y es posible que tenga que solucionarlos, pero eso no es diferente a cualquier otro sistema.

En cuanto a la portabilidad: las aplicaciones ASP.NET son las más fáciles de portar, ya que tienen poca o ninguna dependencia de Win32 e incluso puedes usar el servidor SQL u otras bases de datos populares (hay muchos proveedores de bases de datos agrupadas con Mono).

El portado de Windows.Forms a veces es más complicado porque a los desarrolladores les gusta escapar del entorno limitado de .NET y P / Invocar sus cerebros para configurar cosas tan útiles como cambiar la velocidad de parpadeo del cursor expresada como dos puntos bezier codificados en forma BCD en un wParam. O alguna basura como esa.

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

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

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

La forma más fácil de verificar su proyecto específico es ejecutar el Analizador de Migración Mono (MoMA) . El beneficio es que notificará al equipo de Mono los problemas que le impedirán usar Mono (si corresponde), lo que les permitirá priorizar su trabajo.

Recientemente ejecuté MoMA en SubSonic y encontré solo un problema: un uso extraño de los tipos Nullable. Esa 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 . Se utiliza en algunas aplicaciones grandes, como Wikipedia y el Centro de desarrolladores de Mozilla , y se ha utilizado en aplicaciones integradas como los reproductores de MP3 Sansa y potencia miles de juegos publicados.

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

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

En el lado web, Mono ha implementado suficiente 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 de shell a su host.

De cualquier manera, Mono es genial y estable.

Cosas clave para recordar al crear un programa multiplataforma:

• Use GTK # en lugar de Windows.
• Asegúrese de colocar correctamente sus nombres de archivo
• Use en Path.Separatorlugar de hardcoding "\", también use en Environment.NewLinelugar de "\n".
• No use ninguna llamada P / invocada a la API Win32.
• No use el Registro de Windows.

Yo personalmente uso Mono en un entorno de horario estelar. Ejecuto servidores mono que se ocupan de gigabytes 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 (IDE) tiene un soporte parcial de msbuild, pero básicamente funcionará en cualquier configuración de construcción "REAL" más allá de un simple hello-world (tareas de construcción personalizadas, "propiedades" dinámicas como $ (SolutionDir), configuración real para nombrar algunos muertos -finales)
• xbuild, que DEBERÍA haber sido el sistema de compilación mono-suministrado-msbuild-totalmente compatible-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" del union para entornos Linux ...

Una vez / Durante la construcción de sus cosas, es posible que vea algunas áreas silvestres incluso para el código que DEBERÍA ser compatible como:

• el compilador se enganchó en ciertas construcciones
• y ciertas clases .NET más avanzadas / nuevas que te arrojan basura inesperada (¿XLinq alguien?)
• algunas "características" de tiempo de ejecución inmaduras (límite de almacenamiento dinámico de 3GB EN x64 ... ¡WTF!)

pero al decir que, en general, las cosas comienzan a funcionar muy rápidamente y las soluciones / soluciones son abundantes .

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

He tenido servidores que se ejecutan con mono, procesan 300 GB de datos por día, con toneladas de p / invocaciones y, en general, hacen MUCHO trabajo y se mantienen ACTUALES durante 5-6 meses, incluso con el mono "de vanguardia".

Espero que esto ayude.

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

• La implementación de formularios de Windows es bastante buena ahora. (Consulte Paint-Mono para obtener un puerto de Paint.net que es una aplicación de formularios de Windows bastante complicada. Todo lo que se requería era una capa de emulación para algunas de las llamadas de sistema P-Invoke y no compatibles).
• Path.Combine y Path.Seperator para unir rutas y nombres de archivos.
• El Registro de Windows está bien, siempre y cuando solo lo esté utilizando para almacenar y recuperar datos de sus aplicaciones (es decir, no puede obtener ninguna información sobre Windows, ya que es básicamente un registro para aplicaciones Mono).

Si desea utilizar WPF, no tiene suerte 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 usted:

• usar AppDomains (Ensamblar Load \ Unload) en entornos multiproceso
• No se puede sostener el modelo 'dejarlo fallar'
• Experimente eventos ocasionales de carga pesada durante la ejecución del proceso

Entonces, los hechos.

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

Bueno. Pero si desea utilizar las características de .net 4.0, debe cambiar a las versiones 2.10.xo 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 simple de prueba de esfuerzo para probar instalaciones mono.

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

Utiliza Thread Pool Worker Threads. El trabajador carga dll en AppDomain e intenta hacer algunos trabajos matemáticos. Parte del trabajo tiene muchos hilos, parte es simple. Casi todo el trabajo está vinculado a la CPU, aunque hay algunas lecturas de archivos del disco.

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

• sgen GC segfaults procesa casi inmediatamente
• mono con boehm vive más (de 2 a 5 horas), pero eventualmente falla

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 a partir de la 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

Ambas fallas están de alguna manera conectadas a la lógica de AppDomains, por lo tanto, debe mantenerse alejado de ellas en mono.

Por cierto, el programa probado funcionó 24 horas en la máquina Windows en MS .NET 4.5 env sin ningún error.

En conclusión, me gustaría decir: use mono con precaución. Funciona a primera vista, pero puede fallar fácilmente cuando sea. Te quedaría con un montón de descargas básicas y una gran pérdida de fe en proyectos de código abierto.

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

(Divulgación: he contribuido a Mono en sí, así como a aplicaciones escritas que se ejecutan sobre él).

En muchos casos, puede tomar el código existente y simplemente ejecutarlo en Mono, particularmente si está portando una aplicación ASP.NET.

En algunos casos, puede requerir secciones completamente nuevas de código para que funcione. Si usa System.Windows.Forms, por ejemplo, la aplicación no funcionará sin modificaciones. Del mismo modo, si utiliza algún 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 los sistemas Macintosh.

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

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

¿Sabes lo bueno que es el soporte de la vista previa de Mono 2.0 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 todavía es un poco impredecible en general. Me sorprendió que funcionara tan bien como con algunas de nuestras formas, aunque honestamente.

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

Creo que una gran parte del secreto de admitir Mono es utilizar las herramientas adecuadas desde el principio, por ejemplo, ActiveRecord, log4net, ra-ajax, etc.

Para el tipo de aplicación que estamos construyendo, Mono desafortunadamente no parece estar listo para la producción. Nos impresionó en general, y su rendimiento tanto en Windows como en máquinas EC2, sin embargo, nuestro programa se bloqueó de manera consistente 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:

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

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

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

Este código es muy simple, por ejemplo, ponga algunos datos en HashSets y luego consulte esos HashSets, etc., todos nativos en C #, nada inseguro, sin llamadas a la API. En el CLR de Microsoft, nunca falla y se ejecuta en grandes conjuntos de datos miles de veces bien.

Uno de nuestros muchachos le envió un correo electrónico a Miguel e incluyó el código que causó el problema, aún no hay respuesta. :(

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

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

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

Como cualquier otra aplicación, haga prototipos y pruebas antes de comprometerse por completo, por supuesto.

Otro problema con el que nos encontramos es el software con licencia: si hace referencia a la DLL de otra persona, no puede codificar las incompatibilidades ocultas en ese ensamblado.

Me imagino que si tiene una aplicación con algunos componentes de terceros, puede que se llene. Dudo que muchos proveedores se desarrollen 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 de manera bastante intensa. Vi fallas en las bibliotecas mono (código administrado), fallas en el código nativo y fallas 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.