•  03-07-2019
  •  | 
  •  

Pregunta

He usado C # en Visual Studio con .NET, y he jugado un poco con Mono en openSUSE Linux, pero realmente no entiendo cómo funciona.

Si escribo una aplicación en Windows en .NET, ¿cómo se relaciona esto con Mono? No puedo ejecutar un archivo .exe de Windows en Linux sin Wine, por lo que no me ayuda a ejecutar aplicaciones desarrolladas en Windows.

¿El propósito es simplemente tener una biblioteca .NET equivalente en Linux (y otras) para facilitar el desarrollo multiplataforma? Por ejemplo, si era un negocio y quería llegar a los clientes de Linux, pero realmente quería usar .NET, ¿entonces Mono debería ser mi elección? ¿O hay algo más que me falta?

¿Fue útil?

Solución

Un Windows EXE contiene múltiples " partes " ;. Simplificado , el código .net (= MSIL) es solo una parte del EXE, y también hay un " real " Parte nativa de Windows dentro del EXE que sirve como una especie de lanzador para el .net Framework que luego ejecuta MSIL.

Mono solo tomará la MSIL y la ejecutará, ignorando las cosas nativas de Windows Launcher.

De nuevo, esta es una descripción simplificada.

Edit: Me temo que mi comprensión de los detalles profundos no es lo suficientemente buena como para realmente muchos detalles (sé aproximadamente lo que es un encabezado de PE, pero no realmente los detalles), pero encontré estos enlaces útiles:

Estructura de la Asamblea NET - Parte II

.NET Foundations - Estructura de montaje .NET

Otros consejos

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

Primero, un poco de fondo ...

¿Cómo funciona .NET?

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

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

Al igual que Java, una aplicación .NET está formada por instrucciones en un lenguaje llamado CIL (Common Intermediate Language) que se puede considerar 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 denomina Common Language Runtime (CLR). El equivalente en el mundo de Java se llama la Máquina Virtual de Java (JVM). En Java, el equivalente a CIL se llama código de bytes de Java. CIL a veces se llama MSIL (Microsoft Intermediate Language).

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

Al igual que 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 los ejecutables .NET CIL. El CLR es una aplicación nativa de Windows al igual que los archivos Win32 EXE descritos anteriormente. El CLR en sí mismo es específico de la implementación de Windows y la arquitectura de la computadora en la que fue diseñado para ejecutarse.

No importa con qué lenguaje .NET comience (C #, VisualBasic, F #, IronPython, IronRuby, Boo, etc.), todos se compilan hasta el código de bytes CIL. Puede fácilmente " desmontar " un programa CIL en una forma de lenguaje ensamblador orientado a objetos que los humanos puedan leer fácilmente. 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 ejecuta el ejecutable, justo antes de que realmente se ejecute el código. Esto significa que el código de bytes de CIL se convierte (compila) a un código de 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 de CLR: 1.0, 1.1, 2.0 y 4.0. Debe tener la versión correcta de CLR instalada en su máquina si desea ejecutar los ejecutables .NET dirigidos a ese tiempo de ejecución. El 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 de CLR.

Además del JIT / CLR, .NET proporciona una gran cantidad de bibliotecas (ensamblajes) que conforman el resto del marco .NET y que proporciona una gran cantidad de capacidades y servicios a los que las aplicaciones .NET pueden recurrir. La gran mayoría de estos ensamblajes son código CIL puro que se ejecuta en el CLR. En Windows, algunos hacen llamadas a la API de Win32 también. 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 " marco " asambleas. Algunas versiones de .NET (por ejemplo, 3.0 y 3.5) agregaron ensamblajes de marco adicionales sin actualizar el CLR o los ensamblajes existentes asociados con ese CLR.

El formato del archivo ejecutable portátil (PE) en el que se entrega un archivo Windows .EXE 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. Es por esto que los archivos .NET EXE parecen ejecutarse de forma nativa en Windows.

Bien, entonces, ¿cómo funciona 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 lenguaje C y compilada en un código de lenguaje de 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 del sistema operativo y el tipo de máquina que está utilizando.

Al igual que en Windows, el tiempo de ejecución Mono (CLR) compila el código de bytes 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 igual que " nativo " a Linux como a Windows.

Para portar Mono a una nueva arquitectura, debe portar el JIT / CLR. Esto es como trasladar cualquier aplicación nativa a una nueva plataforma.

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

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

Al igual que en Windows, Mono admite varias versiones de CLR y los ensamblajes asociados:

Las versiones muy tempranas de Mono (¿antes de 1.2?) solo admitían CLR 1.0 o 1.1. Mono no era compatible con grandes partes del framework 2.0 hasta que es su propia versión 2.0.

Las versiones Mono hasta la versión 2.4 son compatibles con las 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 predeterminado.

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

Mono 2.10 sigue usando CLR 4.0 como predeterminado y también es compatible con CLR 2.0.

Al igual que el .NET real (pero en muchos menos casos) hay algunos ensamblados Mono que llaman a las bibliotecas nativas. Para hacer que el ensamblado System.Drawing funcione en Mono, el equipo de Mono escribió un programa Linux para simular la parte GDI + de la API de Win32 en Linux. Esta biblioteca se llama 'libgdiplus'. Si compila Mono desde la fuente, notará que necesita compilar este archivo 'libgdiplus' antes de poder compilar 'mono'. No necesita 'libgdiplus' en Windows porque la parte GDI + 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 las áreas donde el diseño de la biblioteca .NET está demasiado influenciado por el diseño de Windows, y un ajuste inadecuado para sistemas como Mac o Linux, el equipo Mono ha escrito extensiones en el marco .NET. Las extensiones Mono también son solo códigos de bytes CIL y generalmente funcionan bien en .NET.

A diferencia de Windows, Linux generalmente no detecta los ejecutables .NET y ejecuta el CLR de forma predeterminada. El usuario generalmente 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 que se ejecutará.

Para facilitar las cosas a los usuarios, las aplicaciones Mono a menudo se envuelven en un script de shell que inicia el CLR. Esto oculta el hecho de que el CLR se está utilizando como en Windows. También es posible decirle a Linux que inicie el CLR cuando se encuentra un archivo que utiliza el formato PE. Por lo general, esto no se hace ya que el formato de archivo PE también se usa para los ejecutables Windows Win32 nativos que, por supuesto, no admite el CLR (Mono).

No hay ninguna razón técnica por la que Linux no pueda usar un lanzador de PE que luego lance un sistema que entienda el código nativo de Windows (como Wine) o el CLR (Mono) según corresponda. Esto simplemente no se ha hecho a mi conocimiento.

De ida y vuelta

Cualquier código .NET que se mantenga en " totalmente administrado " El código, que significa que no llama a un código que no sea de .NET, debería funcionar bien en Mono en todas las plataformas. Normalmente utilizo ensamblados compilados de .NET desde Windows (para los que 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 proporcionarle a un cliente un código que compilé con Mono y no me preocupo si está en Windows de 32 bits o 64 bits, por ejemplo. El cliente necesita tener la versión correcta de .NET (el CLR correcto) instalado para el curso. CLR 2.0 ha existido durante mucho tiempo y puede apostar que casi todos los usuarios de Windows lo tienen instalado. Los compiladores Mono y otros códigos también son solo archivos ejecutables de CIL, por lo que se ejecutan bien en Windows si lo desea.

La compatibilidad con Mono es lo suficientemente buena como para que grandes fragmentos de código real de Microsoft, como ASP.NET MVC, puedan tomarse (donde sea legal hacerlo) de la versión de MS real de .NET y ejecutarse en Mac o Linux. En general, el equipo de Mono ha hecho un gran trabajo al implementar tanto el CLR como el resto del marco (bibliotecas de clase / ensamblajes).

ASP.NET

En Windows, Internet Information Server (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 nuevas arquitecturas.

Porting Mono

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

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

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

Así es como funciona Mono.

De hecho, puede ejecutar un archivo .NET .exe con Mono en Linux. Esto no requiere vino. De hecho, Mono compila programas en archivos .exe, que pueden ejecutarse con Mono en Linux o como un 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 un lenguaje intermedio neutral para la máquina. El Runtime toma ese código intermedio y lo traduce en código de máquina.

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

Pero como se menciona que Mono es de código abierto y no puede simplemente 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 su La aplicación utilizará, por ejemplo, su aplicación se comunicará con MCI (Interfaz de controlador multimedia) bajo win32. Pero también estaba usando aplicaciones GTK # de escritura mono, pero también usé mis aplicaciones Windows que funcionaron sin ninguna compilación, como mencionamos anteriormente a nuestros compañeros programadores, es decir, mono es una alternativa de código abierto de Microsoft .NET, y por defecto si está creando WinForms o Gtk #. Las aplicaciones mono compilarán y crearán un ensamblado .exe para cada archivo y, por supuesto, si lo desean, crearán una Biblioteca de enlaces dinámicos (DLL), casi como se hace en .NET. Solo por sugerencia, intente escribir un Gtk # (con el IDE de MonoDevelop, que tiene su diseñador de interfaz gráfica de usuario incorporado llamado stetic). Y, por supuesto, mono puede ser un excelente reemplazo para los servicios web que puede crearlos en .NET y puede alojarlos en Apache (debido a que hoy en día el alojamiento de Linux es más barato que los de Windows) y otras aplicaciones asp.net funcionarán. apache con un módulo mod_mono que debe incluirse en apache.

Un poco fuera de tema, pero solo quería contarte un vistazo de mi experiencia.

También puede echar un vistazo a MoMA (si su objetivo es portar aplicaciones de Win a Lin).

  

El analizador de migración Mono (MoMA)   herramienta le ayuda a identificar los problemas que pueda   tener al trasladar tu .Net   Aplicación a Mono. Ayuda a señalar   Llamadas específicas a la plataforma (P / Invoke) y   áreas que aún no son compatibles con   El proyecto Mono.

MoMA

Aquí hay una aplicación web que compara los tipos de BCL ya implementados por Mono y .NET Framework 3.5

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

Para ampliar la respuesta de Michael, creo que tendrá que volver a compilar Mono para que la aplicación se ejecute en el tiempo de ejecución de Mono. Pueden existir excepciones. Solo he jugado un poco con Mono, 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. Se supone que Mono Olive y Moonlight agregan .NET 3.0 (menos WPF) y la funcionalidad Silverlight.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top