¿Mono tiene un lugar en el mundo empresarial?

22

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?

Daniel
fuente

Respuestas:

22

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).

Walter
fuente
55
Bonita historia de guerra.
15

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.

Dilema
fuente
No he tenido dificultades con el soporte de Winforms en Mono. Por supuesto, el resultado no es exactamente una obra de arte, pero eso se debe a que no se está ejecutando en Windows.
Robert Harvey
3
Nota: el marco de la entidad ahora es de código abierto. el equipo mono comenzó a incluirlo en la versión de desarrollo actual
linquize el
@Robert Harvey: Grantet, gran parte de los conceptos básicos funcionan (por ejemplo, botón, vista de árbol, archivos de texto, etiquetas, incluso cuadrículas de datos), pero tan pronto como agrega un divisor, es "excepción no implementada".
Dilema el
14

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).

Adam Lear
fuente
Sí, tienes que controlar qué versión mono usar. El que viene con las distribuciones de Linux suele ser bastante viejo, por lo que tiene más errores. Enviamos esto de vez en cuando desde git mono-2-10 branch para reducir errores y sabemos qué posibles errores puede sufrir nuestro programa.
linquize
3

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.

Jon Hopkins
fuente
3
Comprendí que la especificación CLR / C # no es propietaria y Mono implementa esa especificación sin mucha (o ninguna) dependencia de la fuente .NET original.
Adam Lear
55
@ Anna: Puede que no sea un experto en estas cosas, pero estoy bastante segura de que Mono aún está en riesgo, independientemente de la poca dependencia que tenga de la fuente original de .NET. Esto se debe a las patentes de Microsoft (que pueden hacerse cumplir con o sin Mono copiando el código de Microsoft). Creo que la FSF resumió sucintamente el problema aquí: fsf.org/news/2009-07-mscp-mono
Adam Paynter
3

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).

Mladen Jablanović
fuente
77
Una razón sería que C # es solo un lenguaje más maduro y mejor diseñado que Java, y es más fácil y más sencillo trabajar con él. Eso me parece una razón muy convincente.
Konrad Rudolph
3
@Konrad: Eso es cierto para las versiones recientes de C # (comenzaron de la misma manera, pero evoluciona mucho más rápido que Java). Desafortunadamente, mi experiencia me dice que las empresas rara vez eligen el lenguaje por sus méritos. Por otro lado, tanto .NET como JVM ofrecen lenguajes alternativos, posiblemente mejor diseñados que C # y Java, por lo que realmente no preferiría uno sobre otro basado en eso.
Mladen Jablanović
Si Mono hubiera estado disponible anteriormente, habríamos considerado .Net / Mono para nuestro entorno. Sin embargo, no fue así, así que ahora estamos en el camino de Java. Podemos hacer algo de trabajo en .Net / Mono, pero el entorno principal es Java y se espera que permanezca así durante bastante tiempo. Al ser alguien que trabaja en ambos, no obtengo el ataque de Java de los C # ers. Son MUY similares. El lenguaje C # es ligeramente mejor, pero las bibliotecas Java y los lenguajes JVM adicionales son mejores. Como plataformas en general, son casi iguales. El material de la biblioteca es más importante para mí, por lo que incluso podría darle el visto bueno a Java.
Brian Knoblauch
1
Mono permite usar C # en Linux. C # tiene tantos azúcares sintácticos para facilitar el desarrollo.
linquize
2015: Java es un ciudadano de segunda clase en OS X (Mac). Mono funciona maravillosamente en OS X (aunque WinForms sigue siendo lento y feo). Y con OmniSharp, puede obtener todo tipo de herramientas de edición con calidad IDE en editores que no son IDE (Sublime, Atom, Vim, Emacs).
Kent A.
1

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:

  • Aplicación de consola
  • Aplicación Web

Problemas encontrados:

  • WinForms no es estable: se bloquea al azar.
  • Soporte de idiomas: es posible que la comunidad no conozca bien todos los idiomas, especialmente los dialectos de algunos países / ciudades. Se pueden perder las configuraciones regionales / colaciones correspondientes.
  • Los métodos poco utilizados pueden tener un comportamiento incompatible con .NET.
  • xsp solo es compatible con HTTP 1.0. Actualmente carece de soporte HTTP 1.1.
  • El control del navegador no funciona bien.

Es mejor usar mono internamente (como el sistema ERP) como entorno controlado.

linquizar
fuente
0

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.

tylerl
fuente