c# - para - ¿Debería usar Mono en un proyecto real?

mono sdk 5.12 0 linux (8)

¿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 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?

Encuentro que Mono es básicamente 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, frente a 5-10 veces más lento cuando se ejecuta Mono en Windows (pero en realidad debería quedarse con MS entonces).

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

Escribe muchas pruebas unitarias y asegúrate de que TODAS pasen por debajo de Mono, esto te ahorrará muchos problemas.
A menos que sea absolutamente necesario, NO use su API de incrustació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, incluso, nunca 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 por 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: La razón por la 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 elementos no utilizados.

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.

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 paso en Podcast # 24).

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.

Como se sugirió, siempre que pruebe a fondo, 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 olvídate de 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)

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 originales y no he tenido ningún problema.

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

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

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

Puedes verificar esto

Tenía algo de experiencia con Mono.

Las cosas puras de .NET (como lógica comercial, controladores o 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:

Desarrollo impulsado por componentes : para que el código sea reutilizado por Windows .NET y Mono, mientras que las diferencias se aíslan y se prueban
Integración continua ejecutando y comprobando todo en comparación con Mono y MS.NET, de modo que los posibles problemas puedan descubrirse lo más rápido posible (también se recomienda la implementación automatizada 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 algunas compañías que entrarán en producción con Mono , todavía esperaría antes de llegar allí debido a:

La falta de suites de componentes de interfaz de usuario decentes y comercialmente compatibles
Problemas con la recolección de basura eficiente
No es la mejor experiencia de depuración (compárela 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.