Para soluciones empresariales basadas en Windows, .NET a veces es la mejor opción. ¿Cómo se ve a Mono en las empresas que tienen que usar Linux (o más bien prefieren usar Linux)? Asumiendo que los desarrolladores no son un problema y están familiarizados con .NET / Mono y otros posibles competidores como Java.
¿Funcionaría una empresa mediana / grande Mono en sus servidores en lugar de tecnologías como Java? ¿Conoces alguna de esas compañías?
Respuestas:
Lo usamos en la gran corporación donde trabajo. No lo planeamos desde el inicio del proyecto, pero simplemente funcionó de esa manera.
Teníamos un proyecto interno que desarrollamos en .NET, una vez que ingresamos a UAT, el dueño del negocio quería abrir la aplicación para algunos clientes, así como para el personal interno. La mayoría de nuestros servidores externos (DMZ) están basados en Linux y los servidores de Windows que están en la DMZ no se ajustaban bien (demasiado cerca de su capacidad). En lugar de comprar nuevo hardware, alguien sugirió ejecutar la aplicación en Mono. Pasamos un par de días haciendo nuestras propias pruebas y luego lanzamos la aplicación a QA, luego a UAT. No tuvimos problemas.
Si nos hubieran dado el requisito al comienzo del proyecto, es posible que no hayamos elegido escribirlo en .NET, pero este fue un buen resultado para un cambio de requisito muy, muy tardío. Ahora estamos bastante seguros de que si surgiera nuevamente podríamos implementar con éxito en Mono (aunque creo que eventualmente tendríamos que modificar algún código, creo que tuvimos suerte).
No he usado mono comercialmente, pero lo uso en privado, porque trabajo en una empresa de Windows, pero en privado soy un usuario de Linux (por lo que puedo reutilizar lo que hago en el trabajo).
En general, estoy de acuerdo con Miguel de Icaza quien dice:
- El 25% de las aplicaciones .NET funcionan de fábrica con mono
- otro 25% puede hacerse trabajar en un día o menos
- más del 25% se puede hacer trabajar en una semana
- El último 25% requiere una reescritura completa de la aplicación (WinForms / COM)
Mono funciona bastante bien, pero hay algunos problemas:
- Soporte VB.NET solo para .NET <= 2.0
- Autenticación de Windows no implementada
- WPF no implementado
- Soporte WCF incompleto
- Entity Framework no implementado y no hay planes para implementar
- "Elementos web ASP.NET" no implementado
- Sin compatibilidad con interoperabilidad COM
- La conexión de Sybase para la versión 15.5 (última) no funciona
- Errores e incompletos en la biblioteca de clase C # (por ejemplo, XML tenía errores en mono <2.6)
- El control del navegador web Linux requiere GTK #
Luego los problemas menores:
- Los formularios de Windows funcionan, pero no siempre se representan correctamente
- MonoDevelop no puede diseñar formularios de Windows
- La depuración 'paso a paso' de MonoDevelop realmente no funciona
- El mono servicio se bloquea después de 5 horas ...
Forma lo que puedo decir:
- Los servicios web funcionan excelentemente
- Si ejecuta una aplicación web, funciona bastante bien (si no utiliza WebParts).
- Si ejecuta WindowsForms, no siempre se verá muy bien (por decir lo menos).
- No existe un equivalente funcional para el Servicio de informes de Microsoft (el informe del año fiscal es lo más parecido, pero es lento, tiene errores y está muy incompleto, además de ninguna actividad desde hace más de un año)
- Experimentará problemas si necesita crear documentos de Word o Excel.
Si quieres desarrollar .NET en Linux
- Podría desarrollar ASP.NET allí (la depuración y el paso funcionan muy mal)
- Realmente no puedes desarrollar WinForms en Linux
- Necesita usar GTK # en lugar de WinForms
En otras palabras:
- Mono tiene su lugar en la ejecución de aplicaciones web y servicios web y servidores de correo.
- Pero no es viable ejecutar aplicaciones de WindowsForms, debe escribir aplicaciones con GTK #
- Carece de una solución de informes y soporte de formato de archivo MS (o bibliotecas de trabajo por lo tanto)
Editar (actualización de 2015):
quería agregar que por ahora, la depuración 'paso a paso' funciona excelentemente, y puede usar MonoDevelop para desarrollar aplicaciones web en Linux, incluso con dependencias nuGet. El problema con las bibliotecas de Excel y Word también desapareció, y la estructura de entidades ahora es de código abierto. El resto es más o menos "como está" (no sé si el servicio mono es fijo, pero espero que sí).
Lo que también ha mejorado es que ahora puede tener paquetes actuales para su distribución, lo que significa que no necesita esperar hasta el próximo lanzamiento de, digamos Debian / Ubuntu, hasta que obtenga la última versión mono (sin tener que compilarlos usted mismo) ) Este es un momento más seguro.
Además, con el lanzamiento de Roslyn, el soporte de VB.NET debería mejorar mucho en el futuro cercano.
Mi empresa desarrolla una importante aplicación de escritorio en su mayoría .NET y lanza versiones de Linux que se ejecutan en Mono, por lo que diría que sí, definitivamente hay un lugar para Mono en las soluciones empresariales basadas en Windows.
Empaquetamos Mono con la instalación de nuestra aplicación, sin requerir que los usuarios la instalen por separado (y de esta manera también controlamos la versión).
Creo que la principal preocupación que tendrían muchas empresas son los problemas de licencia entre Mono y Microsoft. Tengo entendido que, si bien Microsoft acordó formalmente que Mono puede usar las tecnologías principales de .NET, pero fuera de eso, incluso sobre cosas muy utilizadas, es más un área gris legalmente, ya que Microsoft no declara una posición firme sobre ella de una manera o de otra. otro.
Obviamente, eso deja abierta la posibilidad de que en el futuro exijan tarifas de licencia o simplemente demanden por violación de patente. Es poco probable que esto ocurra por la forma en que se comportan en este momento, pero a la mayoría de las empresas no les gusta ese tipo de incertidumbre, especialmente cuando se trata de posibles responsabilidades y costos asociados.
No creo que haya mucho espacio para Mono allí:
Java ya es una plataforma establecida en Linux, con una gran comunidad y abundancia de bibliotecas y herramientas de calidad empresarial, tanto comerciales como de código abierto. No veo ninguna razón para elegir Mono sobre Java al comenzar un nuevo proyecto dirigido a Linux (o Mac), a menos que haya alguna circunstancia específica (vea la respuesta de Walter).
Antes de usar mono, debemos asegurarnos de que no haya un '\' codificado para la cadena de ruta (use Path.Combine ()) o el prefijo "COM" (simplemente acepte cadena en lugar de entero) para el puerto serie en el programa.
Lo que funciona bien:
Problemas encontrados:
Es mejor usar mono internamente (como el sistema ERP) como entorno controlado.
Mono es una gran alternativa si ya tiene código .NET que necesita ejecutarse en un entorno multiplataforma. Mono se usa ampliamente en el mundo de los negocios específicamente para resolver este mismo problema.
Yo argumentaría en contra de usar la existencia de Mono como una excusa para comenzar un proyecto con .NET que sabe que necesitará ser multiplataforma. La razón de esto es el retraso entre el estado del arte con .NET versus la velocidad de desarrollo de Mono.
Por otro lado, si tiene la intención de usar Mono en un proyecto futuro, le advertiría que apunte al marco Mono y se ejecute en .NET como alternativa secundaria, ya que Mono es en gran medida un subconjunto de la funcionalidad completa de .NET.