¿Mono es un subconjunto de .NET?

Question

Sé que lo contrario no es cierto, pero si mi aplicación funciona con Mono, ¿está garantizado que funcionará si cambio al trato real? Si no, ¿dónde puedo encontrar una lista de advertencias?

Answer 1

Tanto Mono como .NET son superconjuntos de la familia de especificaciones ECMA/ISO CLI. Sin embargo, ni .NET ni Mono son subconjuntos de la otra. Tanto Mono como .NET agregan funciones sobre la CLI de ECMA/ISO, pero mientras que Mono implementa muchas de las adiciones de .NET, .NET no implementa ninguna de las adiciones de Mono.

He aquí algunos ejemplos:

• Mono tiene matrices más grandes. Esto es realmente no una característica agregada a la especificación ECMA/ISO CLI pero opcional: la especificación dice que los índices de matriz deben ser de 32 bits o de 64 bits. .NET eligió 32 bits, pero Mono eligió 64, ya que las matrices con 10 mil millones de entradas y más son bastante comunes en las aplicaciones de supercomputación, donde Mono tiene una gran cuota de mercado. Por lo tanto, si su aplicación tiene una matriz con varios miles de millones de entradas, se ejecutará perfectamente en Mono, pero no funcionará en .NET.
• Mono tiene continuaciones integradas en la máquina virtual. Estos son importantes para la programación del juego.
• Mono tiene soporte SIMD nativo para operaciones paralelas en matrices, que se asignan a instrucciones nativas de la CPU SIMD (MMX, SSE, VMX).
• Mono tiene el compilador como servicio, del cual Microsoft ha estado hablando vagamente para una versión futura no especificada de .NET.
• Mono tiene una gran cantidad de bibliotecas adicionales, especialmente los enlaces con bibliotecas de gráficos que no sean Windows Forms (wx.NET, GTK #, #, cacao ...)

Tenga en cuenta, sin embargo, que (a excepción de la arrays), todos estos son claramente distinguibles por sus espacios de nombres, ya que ninguno de ellos vive en los espacios de nombres System o Microsoft.

---

EDITAR: En realidad, la mayoría de las extensiones mencionadas anteriormente están explícitamente diseñadas para funcionar también en .NET. Por ejemplo, Mono.Simd también se ejecuta en .NET, pero sin el soporte de tiempo de ejecución que tiene el Mono VM, es inusualmente lento. (Básicamente, todas las operaciones SIMD se implementan en C#, pero el compilador Mono detecta esas llamadas y las reemplaza con sus correspondientes instrucciones de ensamblaje. De esta forma, funcionan en .NET, pero sin el tratamiento especial, son significativamente más lentas). , el C# REPL se está implementando nuevamente en la parte superior de Reflection.Emit (por el momento, llama al compilador Mono directamente), por lo que funcionará en .NET en el futuro. Gtk # funciona bien en Windows y .NET.

Solo la biblioteca Mono.Tasklet no se puede implementar en .NET, ya que requiere soporte de VM para las continuaciones.

Answer 2

No. Mono incluye varios marcos de IU alternativos (Gtk #, wxWindows para .NET, etc.).

Sin embargo, si solo usa clases definidas por Microsoft, debería estar bien.

Answer 3

Mono es una implementación del estándar CLI, al igual que el CLR.

Incluye muchas de las bibliotecas que encontrará en .NET BCL, pero ninguna que sea específica de Windows (WMI es un dominio completo que se le ocurre).

Mientras se mantenga en las características que no son específicas de Windows, debería estar bien.

El equipo mono ha creado una herramienta para comprobar si su código debería funcionar en mono - MoMA, el Analizador de migración mono.

En lo que respecta al uso de código mono con los compiladores de Microsoft, siempre que incluya las bibliotecas que está utilizando y no realice ningún inVoice en Linux, debería estar bien.

Answer 4

Mono no extiende las API de BCL, al menos no en el espacio de nombre System. Por lo tanto, puede estar bastante seguro de que una aplicación que utilice únicamente tipos del espacio de nombre System será portátil sin recompilación de Mono a .NET. Por supuesto, no encontrará nada en el espacio de nombres Mono una vez que esté en .NET world.

Desde el Mono FAQ:

¿Tiene planes de adoptar y extender .NET?

Adoptar una buena tecnología es bueno. Extender las tecnologías en formas incompatibles es malo para los usuarios, por lo que hacemos no planea hacer cambios incompatibles en las tecnologías.

Si tienes ideas innovadoras, y desea para crear nuevas clases, que animar a a hacer esas clases funcionan correctamente bien tanto en Mono y .NET. Hoy Mono se envía con un número de bibliotecas extra que fueron desarrolladas por miembros de la comunidad Mono u otros grupos. En algunos casos , se han encontrado los bits de Microsoft que está incompleta, pero evitar la ruptura de la API, en lugar de eso expone la funcionalidad que falta en nuevos montajes (véase Mono.Security)