¿Está Mono listo para la hora de máxima audiencia

.net open-source mono


¿Alguien ha usado Mono, la implementación de .NET de código abierto en un proyecto grande o mediano? Me pregunto si está listo para entornos de producción del mundo real. ¿Es estable, rápido, compatible, ... lo suficiente para usar? ¿Se necesita mucho esfuerzo para portar 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?




Answer 1 miguel.de.icaza


Hay un par de escenarios a considerar:a)si estás portando una aplicación existente y te preguntas si Mono es lo suficientemente bueno para esta tarea;b)si estás empezando a escribir algún código nuevo,y quieres saber si Mono es lo suficientemente maduro.

Para el primer caso, puede usar la herramienta Mono Migration Analyzer (Moma) para evaluar qué tan lejos está su aplicación de ejecutarse en Mono. Si la evaluación vuelve con gran éxito, debe comenzar con las pruebas y el control de calidad y prepararse para el envío.

Si su evaluación vuelve con un informe en el que se destacan las características que faltan o que difieren significativamente en su semántica en Mono,tendrá que evaluar si el código puede ser adaptado,reescrito o,en el peor de los casos,si su aplicación puede funcionar con una funcionalidad reducida.

De acuerdo con nuestras estadísticas del Moma basadas en los envíos de los usuarios (esto es de memoria)cerca del 50% de las aplicaciones funcionan fuera de la caja,cerca del 25% requieren cerca de una semana de trabajo (refactorización,adaptación)otro 15% requiere un compromiso serio para rehacer trozos de su código,y el resto no vale la pena molestarse en portarlo ya que están tan increíblemente ligados a Win32.En ese punto,o se empieza de cero,o una decisión de negocios impulsará el esfuerzo de hacer portátil su código,pero estamos hablando de meses de trabajo (al menos por los informes que tenemos).

Si empiezas de cero,la situación es mucho más simple,porque sólo usarás las APIs que están presentes en Mono.Siempre y cuando permanezcas con la pila soportada (que es más o menos .NET 2.0,más todas las actualizaciones del núcleo en 3.5 incluyendo LINQ y System.Core,más cualquiera de las APIs multiplataforma de Mono)estarás bien.

De vez en cuando puedes encontrarte con bichos en Mono o limitaciones,y puede que tengas que trabajar alrededor de ellos,pero eso no es diferente de cualquier otro sistema.

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

La portabilidad de las formas es a veces más difícil porque a los desarrolladores les gusta escapar de la caja de arena de .NET y P/Invoque sus cerebros para configurar cosas tan útiles como el cambio de la tasa de parpadeo del cursor expresado como dos puntos bezier codificados en forma BCD en un wParam.O alguna basura como esa.




Answer 2 Jon Galloway


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

  • Windows Presentation Foundation
  • Windows Workflow Foundation (ninguna de las dos versiones)
  • Marco de Entidades
  • Los "complementos" WSE1/WSE2 de la pila estándar de Servicios Web

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

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

Recientemente corrí el MoMA en SubSonic y encontré sólo un problema-un uso extraño de los tipos anulables.Es una gran base de código,así que la cobertura allí fue bastante impresionante.

Mono se utiliza activamente en varios productos comerciales y de código abierto . Está en uso en algunas aplicaciones grandes, como Wikipedia y Mozilla Developer Center , y se ha utilizado en aplicaciones integradas como los reproductores 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 .




Answer 3 FlySwat


En el lado del escritorio,Mono funciona muy bien si te comprometes a usar GTK#.La implementación de Windows.Forms es todavía un poco problemática (por ejemplo,los TrayIcon no funcionan)pero ha avanzado mucho.Además,GTK#es un mejor kit de herramientas que Windows Forms tal como está.

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

De cualquier manera,Mono es genial,y estable.

Cosas clave a recordar cuando se crea un programa de plataformas cruzadas:

  • Utilice GTK#en lugar de Windows.Formularios
  • Asegúrense de que los nombres de los archivos estén bien guardados...
  • Use Path.Separator en lugar de codificar "\" , también use Environment.NewLine en lugar de "\n" .
  • No uses ninguna llamada P/Invoked a la API de Win32.
  • No utilice el Registro de Windows.



Answer 4 damageboy


Yo personalmente uso Mono en un envolvente de primera hora.Dirijo servidores mono que tratan con giga-bytes de tareas relacionadas con el procesamiento de datos udp/tcp y no podría estar más contento.

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

  • MonoDevelop (el IDE)tiene algo de soporte parcial de msbuild,pero básicamente funcionará en cualquier conf de construcción "REAL" más allá de un simple hola-mundo (tareas de construcción personalizadas,"propiedades" dinámicas como $(SolutionDir),configuración real por nombrar algunos callejones sin salida)
  • xbuild, que DEBERÍA haber sido el sistema de compilación totalmente compatible mono-proporcionado-msbuild-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 tus cosas,puedes ver algunas zonas salvajes incluso para el código que DEBERÍA ser soportado:

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

pero Heaving dijo que, en general, las cosas comienzan a funcionar muy rápido y las soluciones / soluciones son abundantes .

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

He tenido servidores funcionando con mono,procesando 300GB de datos por día,con toneladas de p/invitaciones y en general haciendo MUCHO trabajo y manteniéndose en pie durante 5-6 meses,incluso con el "borde sangrante" de la mono.

Espero que esto ayude.




Answer 5 Kris Erickson


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 ver una adaptación de Paint.net, que es una aplicación de formularios de Windows bastante complicada. Todo lo que se necesitaba era una capa de emulación para algunas de las llamadas de P-Invoke y del sistema no admitidas).
  • Path.Combine así como Path.Seperator para unir caminos y nombres de archivos.
  • El registro de Windows está bien,siempre y cuando sólo lo utilice para almacenar y recuperar datos de sus aplicaciones (es decir,no puede obtener ninguna información sobre Windows a partir de él,ya que es básicamente un registro para aplicaciones Mono).