¿Debo usar Mono en un proyecto real?

Question

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

Answer 1

Lo he usado para una serie de proyectos internos y comerciales con gran éxito. Mis advertencias:

• Escriba un montón de pruebas unitarias y asegúrese de que TODAS pasen bajo Mono - esto le ahorrará muchos problemas.
• A menos que sea absolutamente necesario, NO use su API de inserción. Es muy fácil de usar, pero es terriblemente fácil que la basura recolecte memoria válida o escape toda tu memoria.
• Nunca, nunca, ni siquiera se acerque a SVN y, a menos que no haya otra opción, no compile la suya. Las cosas cambian tan a menudo en SVN que es muy probable que termine implementando algo que no funciona en una versión de lanzamiento si su proyecto es significativamente grande.
• No intente resolver problemas por su cuenta durante mucho tiempo, use el canal IRC. La gente de allí es útil y te ahorrarás días y días; no cometas el mismo error que yo.

¡Buena suerte!

Editar: El motivo por el que digo que no compile el suyo desde el origen (versión o SVN) es que es fácil configurarlo de forma diferente que lanzar binarios y ocultar errores, por ejemplo en la recolección de basura.

Editar 2: Se olvidó de responder la segunda parte de su pregunta. En mi caso, no tuve problemas con el código de portado, pero no estaba usando ninguna biblioteca específica de MS (WinForms, ASP.NET, etc.). Si solo estás utilizando System. *, Estarás bien; más allá de eso, puede encontrarse con problemas. Sin embargo, Mono 2.0 es bastante sólido.

Answer 2

No he usado Mono por mi cuenta, pero puede que le interese saber que FogBugz usa Mono para proporcionar Lucene.NET en plataformas Linux. (Solo sé esto porque Joel lo mencionó de pasada en Stack Overflow Podcast # 24.)

Answer 3

Si está haciendo el trabajo ASP.NET 2.0, funciona muy bien. Las Winforms pueden funcionar, pero pueden causar problemas de visualización. Si desea compatibilidad en una aplicación de formularios, sugeriría GTK #, ya que es una plataforma cruzada.

Al igual que lo sugerido, siempre que pruebe exhaustivamente, estaría de acuerdo en usarlo comercialmente si esa es una opción viable para usted, a menos que sea una forma segura que necesite. En mi opinión, me mantendría alejado de él por ahora. Y olvide WPF, ya que no hay soporte en este momento, y puede que nunca lo haya (aunque están trabajando en moonlight, también conocido como silverlight for linux)

Answer 4

Encuentro que Mono es principalmente compatible con MS. Por lo tanto, simplemente compilo con MS y corro a cualquier lugar, ¡como debería ser Java!

El rendimiento de Mono en Linux se acerca mucho a MS, tan solo 2 veces más lento en algunos casos, vs 5-10 veces más lento cuando se ejecuta Mono en Windows (pero en realidad debería seguir con MS entonces).

Answer 5

Tengo un montón de aplicaciones de shell en producción.

Estoy de acuerdo con @cody-brocious, escribo muchas pruebas unitarias. Encontré en el pasado que las Expresiones regulares no funcionaban exactamente de la misma manera que las ventanas CLR.

En realidad, es más simple de lo que piensas, solo compila y ejecuta. Si utiliza NAnt en sus proyectos, es aún más fácil hacer la transición.

Normalmente instalo mono de las versiones de origen y no he tenido ningún problema.

Answer 6

Lo he usado para herramientas de cifrado/descifrado y funcionó bien.

En el futuro, consideraría usar Mono/C#, pero no esperaría que fuera 100% exactamente como .Net en Windows.

Answer 7

Por supuesto, puede hacerlo, especialmente después de que se haya lanzado Mono 2.0. Mono 2.0, está listo para proyectos reales.

You can check this

Answer 8

que tenían alguna experiencia con Mono.

Las cosas de .NET puro (como la lógica empresarial, los controladores o los algoritmos) se pueden portar sin ningún problema. Sin embargo, empiezan a aparecer cosas raras en los componentes que interactúan con el sistema operativo, la interfaz de usuario, los servicios o la persistencia. Así que prepárate para la depuración y el pirateo.

cosas que pueden ayudar:

• Component-Driven Development - para que el código se vuelve a utilizar por Windows .NET y Mono, mientras que las diferencias son aislados y probados)
• Continuous Integration ejecución y el control de todo en contra Mono y MS.NET , para que los posibles problemas puedan descubrirse lo más rápido posible (también se recomienda el despliegue automatizado y las comprobaciones de cordura)
• No hay muchas suites de componentes de interfaz de usuario para el desarrollo de shell en Mono.
• Cuando un proveedor de componentes dice que su código es "compatible con Mono", no es lo mismo que "se ejecuta en Mono y es compatible".

Aunque en el presente, hay algunos companies going into production with Mono, todavía me gustaría esperar antes de salir corriendo de allí debido a:

• La falta de componentes de interfaz de usuario suites dignas y soporte comercial
• problemas con la basura eficiente colección
• No es la mejor experiencia de depuración (compárese con el depurador histórico en VS 2010)

PD: si hay una compañía que ofrece una solución de computación en la nube totalmente administrada (no solo una VM, sino más bien un equivalente de Hadoop para .NET), entonces me veré obligado a saltar a pesar de estos problemas.