Cómo funciona Mono

Esta es una pregunta antigua (con una respuesta ya seleccionada) pero no creo que la pregunta realmente haya sido respondida bien.

Primero, un poco de fondo...

¿Cómo funciona. NET?

Una Ventana tradicional .El archivo EXE es un archivo binario que representa una serie de instrucciones de lenguaje de máquina que su computadora entiende y que hace llamadas a la API Win32 que son partes de Windows que brindan servicios que las aplicaciones pueden aprovechar. El el lenguaje de máquina utilizado es muy específico para su tipo de equipo y las llamadas a Win32 hacen que el ejecutable sea muy dependiente de Windows. Un ejecutable. NET no es así.

Es importante darse cuenta de que un ejecutable.NET (.Archivo EXE) no es en realidad una aplicación nativa de Windows. Windows no entiende cómo ejecutar el código en un ejecutable. NET. Tu ordenador tampoco lo entiende.

Al igual que Java, una aplicación. NET se compone de instrucciones en un lenguaje llamado CIL (Common Intermediate Language) que se puede pensar como el lenguaje de máquina para una computadora idealizada que realmente no existe. En. NET, la implementación de software de esta máquina idealizada se llama Common Language Runtime (CLR). El equivalente en el mundo Java se llama Java Virtual Machine (JVM). En Java, el equivalente a CIL se llama Java bytecode. CIL a veces se llama MSIL (Lenguaje intermedio de Microsoft).

CIL está diseñado para ejecutarse en el CLR (un máquina idealizada), pero por lo demás es independiente de la plataforma, lo que significa que al CIL no le importa qué tipo de computadora tiene o qué sistema operativo está ejecutando.

Así como necesita una versión nativa de Java JVM en cada plataforma en la que desea ejecutar Java, necesita una versión nativa de CLR para ejecutar ejecutables.NET CIL. El CLR es una aplicación nativa de Windows al igual que los archivos Win32 EXE tradicionales descritos anteriormente. El CLR en sí es específico para las Ventanas implementación y arquitectura informática en la que fue diseñado para ejecutarse.

No importa con qué idioma.NET comience (C#, VisualBasic, F#, IronPython, IronRuby, Boo, etc.), todos ellos se compilan hasta CIL bytecode. Puede "desmontar" fácilmente un programa CIL en una forma de lenguaje ensamblador orientado a objetos que sea fácilmente legible por los humanos. Puedes escribir un programa en CIL directamente tú mismo, pero pocas personas lo hacen.

En Windows, el CLR compila este código CIL Just-in-Time (JIT) justo cuando se ejecuta el ejecutable just justo antes de que el código se ejecute realmente. Esto significa que el bytecode CIL se convierte (compila) en código máquina real que se ejecuta de forma nativa en su computadora. Esta parte del CLR se llama el compilador JIT o a menudo solo el JIT.

Hasta la fecha, Microsoft ha lanzado cuatro versiones del CLR: 1.0, 1.1, 2.0 y 4.0. Necesita tener la versión correcta del CLR instalada en su máquina si desea ejecutar ejecutables. NET dirigidos a ejecución. CLR 2.0 admite aplicaciones.NET 2.0, 3.0 y 3.5. Para otras versiones de. NET, la versión de. NET se asigna limpiamente a la versión CLR.

Además del JIT/CLR,. NET proporciona una serie de bibliotecas (ensamblados) que conforman el resto de. NET framework y que proporcionan una serie de capacidades y servicios a los que las aplicaciones. NET pueden recurrir. La gran mayoría de estas asambleas son código CIL puro que se ejecuta en el CLR. En Windows, algunos hacen llamadas a la API de Win32 como bien. Cuando instala. NET, está instalando el CLR, las bibliotecas de clases (framework) y un montón de herramientas de desarrollo. Cada versión del CLR generalmente requiere un conjunto completo de estos ensamblados de" framework". Algunas versiones de.NET (por ejemplo. 3.0 y 3.5) se agregaron ensamblados de marco adicionales sin actualizar el CLR o los ensamblados existentes asociados con ese CLR.

El formato de archivo Ejecutable portátil (PE) que un Windows .El archivo EXE se entrega en contiene un encabezado que describe el ejecutable e identifica el archivo como un archivo.NET o un archivo Win32 nativo. Cuando Windows intenta ejecutar un archivo. NET, ve este encabezado e invoca automáticamente el CLR en su nombre. Esta es la razón por la que los archivos.NET EXE parecen ejecutarse de forma nativa en Windows.

Bien, ¿cómo funciona el Mono?

Mono implementa el CLR en Linux, Mac y otras plataformas. El tiempo de ejecución Mono (CLR) es una aplicación nativa escrita principalmente en el lenguaje C y compilada en código de lenguaje máquina para el sistema informático en el que está diseñado para ejecutarse. Al igual que en Windows, el tiempo de ejecución Mono es específico para el Sistema Operativo y el tipo de máquina que está utilizando.

Al igual que en Windows, el tiempo de ejecución Mono (el CLR) compila el bytecode CIL en su ejecutable.NET Just-in-time a código nativo que su computadora puede entender y ejecutar. De esta manera, un archivo.NET es tan "nativo" para Linux como para Windows.

Para portar Mono a una nueva arquitectura necesita portar el JIT/CLR. Esto es al igual que portar cualquier aplicación nativa a una nueva plataforma.

Qué tan bien se ejecuta el código.NET en Linux o Mac es realmente solo una cuestión de qué tan bien se implementa el CLR en estos sistemas. En teoría, el CLR Mono podría ejecutar código. NET en estos sistemas mucho mejor que la versión MS de. NET en Windows. En la práctica, la aplicación de los Estados miembros es generalmente superior (aunque no en todos los casos).

Además del CLR, Mono proporciona la mayor parte del resto de bibliotecas (ensamblados) que cree el. NET framework. Al igual que con la versión de Microsoft de.NET (de hecho más) los ensamblados Mono se proporcionan como código de bytes CIL. Esto hace posible tomar un*.dll o *.archivo exe de Mono y ejecutarlo sin modificar en Windows, Mac o Linux como CIL es el lenguaje "nativo" de las implementaciones de CLR en estos sistemas.

Al igual que en Windows, Mono soporta múltiples versiones del CLR y los ensamblados asociados:

Versiones muy tempranas de Mono (antes de la 1.2?) solo compatible con CLR 1.0 o 1.1. Mono no soportaba grandes partes del framework 2.0 hasta que era su propia versión 2.0.

Las versiones Mono hasta la versión 2.4 soportaban aplicaciones CLR 1.1 y CLR 2.0.

A partir de Mono 2.6, se agregó CLR 4.0, pero CLR 2.0 seguía siendo el valor predeterminado.

A partir de Mono 2.8 el CLR 4.0 se convirtió en el valor predeterminado y el CLR 1.1 ya no es compatible.

Mono 2.10 continúa usando el CLR 4.0 por defecto y también para soportar el CLR 2.0.

Al igual que el.NET real (pero en muchos menos casos) hay algunos ensamblados Mono que llaman a bibliotecas nativas. Para hacer el Sistema.Dibujando el trabajo de ensamblaje en Mono, el equipo Mono escribió un programa Linux para simular la porción GDI+ de la API Win32 en Linux. Esta biblioteca se llama 'libgdiplus'. Si compila Mono desde el código fuente, notará que necesita compilar este archivo 'libgdiplus' antes de poder compilar 'mono'. No necesita 'libgdiplus' en Windows porque el GDI+ parte de la API de Win32 ya es parte de Windows. Un puerto completo de Mono a nuevas plataformas requiere que esta biblioteca' libgdiplus ' también sea portada.

En áreas donde el diseño de la biblioteca.NET está excesivamente influenciado por el diseño de Windows, y un mal ajuste para sistemas como Mac o Linux, el equipo Mono ha escrito extensiones para. NET framework. Las extensiones Mono también son solo CIL bytecode y generalmente funcionan bien en .NET.

A diferencia de Windows, Linux generalmente no detecte ejecutables. NET e inicie el CLR de forma predeterminada. Por lo general, el usuario debe ejecutar el CLR directamente escribiendo 'mono appname.exe " o algo similar. Aquí 'mono' es la aplicación que implementa el CLR y ' appname.exe ' es el archivo EXE que contiene el código. NET a ejecutar.

Para facilitar las cosas a los usuarios, las aplicaciones Mono a menudo están envueltas en un script de shell que inicia el CLR. Esto oculta el hecho de que el CLR se está utilizando al igual que en Windows. También es posible decir Linux para iniciar el CLR cuando se encuentra un archivo que utiliza el formato de archivo PE. Esto generalmente no se hace ya que el formato de archivo PE también se utiliza para ejecutables nativos de Windows Win32 que, por supuesto, el CLR (Mono) no es compatible.

No hay ninguna razón técnica por la que un lanzador PE no pueda ser utilizado por Linux, que luego lanza un sistema que entiende el código nativo de Windows (como Wine) o el CLR (Mono) según corresponda. Esto simplemente no se ha hecho que yo sepa.

Volver y forth

Cualquier código. NET que se adhiera al código "totalmente administrado", lo que significa que no llama a non-.NET código, debe funcionar bien en Mono en todas las plataformas. Uso rutinariamente ensamblados. NET compilados desde Windows (para los cuales no tengo el código) en Linux y Mac.

También puedo tomar cualquier código que compile en Mono y ejecutarlo en.NET en Windows. Puedo proporcionar a un cliente algún código que compilé con Mono y no preocuparse si está en Windows de 32 bits o 64 bits, por ejemplo. El cliente necesita tener instalada la versión correcta de.NET (el CLR correcto) para el curso. CLR 2.0 ha existido durante mucho tiempo y puede apostar a que casi todos los usuarios de Windows lo tienen instalado. Los compiladores Mono y otro código también son solo ejecutables CIL y por lo que se ejecutan bien en Windows si lo desea.

La compatibilidad Mono es lo suficientemente buena como para que grandes trozos de código real de Microsoft, como ASP.NET MVC, se puede tomar (cuando sea legal hacerlo) de la versión MS real de.NET y ejecutarse en Mac o Linux. En en general, el equipo Mono ha hecho un gran trabajo implementando tanto el CLR como el resto del framework (bibliotecas de clases/ensamblajes).

ASP.NET

En Windows, el Servidor de Información de Internet (IIS) sabe cómo llamar al CLR para ejecutar.NET como parte de una aplicación web. En Linux / Mac hay un módulo Apache (mod_mono) que proporciona capacidades similares al servidor web Apache. Esta aplicación está escrita en C y también debe ser portada a new arquitectura.

Portando Mono

Esta discusión ha identificado partes de Mono que se construyen como ejecutables "nativos" y deben existir en un sistema en el que desea ejecutar aplicaciones.NET.

• El CLR (incluyendo el compilador JIT) - generalmente conocido como Mono
• libgdiplus (para sistemas que no admiten de forma nativa la API GDI+ [solo Windows lo hace])
• mod_mono (para permitir que Apache invoque el CLR para. NET web aplicaciones)

Estos tres componentes, con la adición de las bibliotecas de clases, proporcionan un entorno.NET que parece "nativo" para los archivos ejecutables. NET que necesita ejecutar.

Así es como funciona Mono.

De hecho, puede ejecutar un .NET.archivo exe con Mono en Linux. Esto no requiere Vino. De hecho, Mono compila programas para .archivos exe, que pueden ejecutarse con Mono en Linux o como ejecutable en Windows.

Mono es una implementación de código abierto de Microsofts.NET CLR (Common Language Runtime). Esto es lo que ejecuta parte de los programas.NET que no están en código nativo sino en CIL (Common Intermediate Language), un lenguaje y lenguaje intermedio neutro para máquinas. El Tiempo de ejecución toma ese código intermedio y lo traduce en código máquina.

En el estado actual de Mono, puede tomar programas.NET que usan las partes principales de. NET (mscorlib.dll) y ejecutarlos en todas partes Mono se ejecuta, no solo Windows.

Pero como se menciona que Mono es de código abierto y no puede confiar en que será la implementación completa de.NET, tiene algunos controles que no funcionan, también debe tener cuidado con P/Invokes que usará su aplicación, por ejemplo, su aplicación se comunicará con MCI (Interfaz de Controlador Multimedia) bajo win32. Pero yo estaba usando mono escribir GTK # Aplicaciones también, pero también he utilizado mis aplicaciones de Windows que funcionaban sin ninguna recompilación como se mencionó nuestro compañero los programadores anteriores, es decir, mono es una alternativa de código abierto de. NET de Microsoft, y por defecto si está construyendo WinForms o Gtk# aplicaciones mono compilará y creará un .ensamblado exe para cada archivo, y por supuesto si lo desea creará una Biblioteca de Enlaces Dinámicos (DLL), casi como se hace en. NET. Solo por sugerencia intente escribir algo de Gtk# (con MonoDevelop IDE que tiene su diseñador gui incorporado llamado stetic). Y por supuesto mono puede ser un gran reemplazo para Web Servicios que se pueden crear en. NET y se pueden alojar en Apache (porque Linux hosting hoy en día son más baratos que los de Windows) servicios web y otros asp.net las aplicaciones funcionarán bajo apache con un módulo mod_mono que debe estar incluido en apache.

Un poco fuera de tema, pero solo quería contarles un adelanto de mi experiencia.

También puedes echar un vistazo al MoMA (si tu objetivo es portar aplicaciones de Win a Lin).

El Analizador de Migración Mono (MoMA) la herramienta le ayuda a identificar los problemas que puede tener al trasladar su .Net aplicación a Mono. Ayuda a identificar llamadas específicas de la plataforma (P / Invoke) y áreas que aún no son apoyadas por el proyecto Mono.

MoMA

Aquí hay una webapp que compara los tipos de BCL ya implementados por Mono y. NET Marco 3.5

Http://mono.ximian.com/class-status/2.0-vs-3.5/index.html

Para ampliar la respuesta de Michael, creo que tendrás que recompilar en Mono para que la aplicación se ejecute en el tiempo de ejecución Mono. Pueden existir excepciones. Solo he jugado con Mono un poco, y siempre he vuelto a compilar la fuente. Nunca he intentado ejecutar una aplicación. NET directamente en Mono.

Además, se supone que Mono 1.9 es totalmente compatible con.NET 2.0. Mono Olive y Moonlight se supone que añaden. NET 3.0 (menos WPF) y funcionalidad Silverlight.

Podría ayudarte, ¿Cómo funciona el compilador C# de Mono? y también Entendiendo el compilador Mono C# book.