•  03-07-2019
  •  | 
  •  

Domanda

Ho usato C # in Visual Studio con .NET e ho giocato un po 'con Mono su openSUSE Linux, ma non capisco davvero come funzioni.

Se scrivo un'app in Windows su .NET, come si collega a Mono? Non posso semplicemente eseguire un file .exe di Windows su Linux senza Wine, quindi non mi aiuta a eseguire app sviluppate in Windows.

Lo scopo è semplicemente quello di avere una libreria .NET equivalente su Linux (e altri) per facilitare lo sviluppo multipiattaforma? Ad esempio, se fossi un'azienda e volessi raggiungere i clienti Linux, ma volessi davvero usare .NET, allora Mono dovrebbe essere la mia scelta? O c'è qualcosa in più che mi manca?

È stato utile?

Soluzione

Un EXE di Windows contiene più "parti". Semplificato , il codice .net (= MSIL) è solo una parte del file EXE e esiste anche un "reale" parte nativa di Windows all'interno di EXE che funge da una sorta di launcher per il .net Framework che esegue quindi MSIL.

Mono prenderà MSIL ed eseguirà, ignorando le cose native di Windows Launcher.

Ancora una volta, questa è una panoramica semplificata.

Modifica: Temo che la mia comprensione dei dettagli profondi non sia abbastanza buona per molti dettagli (so più o meno cosa sia un PE Header, ma non i dettagli), ma ho trovato questi link utili:

Struttura dell'assieme NET - Parte II

Foundations .NET - Struttura dell'assembly .NET

Altri suggerimenti

Questa è una vecchia domanda (con una risposta già selezionata) ma non credo che alla domanda sia stata davvero data una buona risposta.

Innanzitutto, un po 'di sfondo ...

Come funziona .NET?

Un file .EXE di Windows tradizionale è un file binario che rappresenta una serie di istruzioni in linguaggio macchina che il tuo computer comprende e che effettua chiamate nell'API Win32 che sono parti di Windows che forniscono servizi di cui le applicazioni possono usufruire. Il linguaggio macchina utilizzato è molto specifico per il tuo tipo di computer e le chiamate Win32 rendono l'eseguibile molto dipendente da Windows. Un eseguibile .NET non è così.

È importante rendersi conto che un eseguibile .NET (file .EXE) non è in realtà un'applicazione Windows nativa. Windows stesso non capisce come eseguire il codice in un eseguibile .NET. Anche il tuo computer non lo capisce.

Proprio come Java, un'applicazione .NET è formata da istruzioni in un linguaggio chiamato CIL (Common Intermediate Language) che puoi pensare come il linguaggio macchina per un computer idealizzato che non esiste realmente. In .NET, l'implementazione software di questa macchina idealizzata è chiamata Common Language Runtime (CLR). L'equivalente nel mondo Java si chiama Java Virtual Machine (JVM). In Java, l'equivalente di CIL si chiama Java bytecode. CIL è talvolta chiamato MSIL (Microsoft Intermediate Language).

CIL è progettato per funzionare sul CLR (una macchina idealizzata) ma è indipendente dalla piattaforma, il che significa che al CIL non importa quale tipo di computer hai o quale sistema operativo stai eseguendo.

Proprio come è necessaria una versione nativa di JVM Java su ciascuna piattaforma su cui si desidera eseguire Java, è necessaria una versione nativa di CLR per eseguire eseguibili .NET CIL. Il CLR è un'applicazione Windows nativa proprio come i tradizionali file Win32 EXE descritti sopra. Il CLR stesso è specifico per l'implementazione di Windows e l'architettura del computer su cui è stato progettato per l'esecuzione.

Non importa con quale linguaggio .NET inizi (C #, VisualBasic, F #, IronPython, IronRuby, Boo, ecc.), vengono tutti compilati in bytecode CIL. Puoi facilmente " smontare " un programma CIL in una forma di linguaggio assembly orientato agli oggetti che è facilmente leggibile dagli umani. Puoi scrivere un programma in CIL direttamente da solo, ma poche persone lo fanno.

Su Windows, il CLR compila questo codice CIL Just-in-Time (JIT) proprio quando si esegue l'eseguibile, appena prima che il codice venga effettivamente eseguito. Ciò significa che il bytecode CIL viene convertito (compilato) in codice macchina reale che viene eseguito in modo nativo sul computer. Questa parte del CLR è chiamata compilatore JIT o spesso solo JIT.

Ad oggi, Microsoft ha rilasciato quattro versioni del CLR: 1.0, 1.1, 2.0 e 4.0. È necessario disporre della versione corretta del CLR installata sul proprio computer se si desidera eseguire eseguibili .NET destinati a quel runtime. CLR 2.0 supporta le applicazioni .NET 2.0, 3.0 e 3.5. Per altre versioni di .NET, la versione .NET si associa perfettamente alla versione CLR.

Oltre a JIT / CLR, .NET fornisce una serie di librerie (assembly) che compongono il resto del framework .NET e che forniscono una serie di funzionalità e servizi su cui le applicazioni .NET possono fare affidamento. La grande maggioranza di questi assiemi è puro codice CIL che viene eseguito sul CLR. Su Windows, alcuni effettuano chiamate anche nell'API Win32. Quando installi .NET, stai installando il CLR, le librerie di classi (framework) e una serie di strumenti di sviluppo. Ogni versione del CLR richiede generalmente un set completo di questi "framework" assiemi. Alcune versioni di .NET (ad es. 3.0 e 3.5) hanno aggiunto assembly di framework aggiuntivi senza aggiornare il CLR o gli assembly esistenti associati a quel CLR.

Il formato di file Portable Executable (PE) in cui viene consegnato un file .EXE di Windows contiene un'intestazione che descrive l'eseguibile e identifica il file come un file .NET o un file Win32 nativo. Quando Windows tenta di eseguire un file .NET, vede questa intestazione e invoca automaticamente il CLR per tuo conto. Questo è il motivo per cui i file EXE .NET sembrano funzionare nativamente su Windows.

Ok, quindi come funziona Mono?

Mono implementa il CLR su Linux, Mac e altre piattaforme. Il runtime Mono (CLR) è un'applicazione nativa scritta principalmente in linguaggio C e compilata in codice linguaggio macchina per il sistema informatico su cui è progettata per essere eseguita. Come su Windows, il runtime Mono è specifico del sistema operativo e del tipo di macchina in uso.

Proprio come su Windows, il runtime Mono (CLR) compila il bytecode CIL nel tuo eseguibile .NET Just-in-time in codice nativo che il tuo computer può capire ed eseguire. In questo modo, un file .NET è esattamente come " native " a Linux come a Windows.

Per eseguire il porting di Mono su una nuova architettura è necessario eseguire il porting di JIT / CLR. È come eseguire il porting di qualsiasi applicazione nativa su una nuova piattaforma.

Quanto bene funziona il codice .NET su Linux o Mac è solo una questione di come il CLR è implementato su questi sistemi. In teoria, il CLR Mono potrebbe eseguire il codice .NET su questi sistemi molto meglio della versione MS di .NET su Windows. In pratica, l'attuazione degli Stati membri è generalmente superiore (sebbene non in tutti i casi).

Oltre al CLR, Mono fornisce la maggior parte del resto delle librerie (assembly) che compongono il framework .NET. Proprio come con la versione Microsoft di .NET (anzi di più) gli assembly Mono sono forniti come bytecode CIL. Questo rende possibile prendere un file * .dll o * .exe da Mono ed eseguirlo non modificato su Windows, Mac o Linux poiché CIL è il "nativo" linguaggio delle implementazioni CLR su questi sistemi.

Proprio come su Windows, Mono supporta più versioni del CLR e degli assiemi associati:

Le versioni molto precedenti di Mono (prima della 1.2?) supportavano solo CLR 1.0 o 1.1. Mono non supportava grossi blocchi del framework 2.0 fino alla sua versione 2.0.

Le versioni mono fino alla versione 2.4 supportavano entrambe le applicazioni CLR 1.1 e CLR 2.0.

A partire da Mono 2.6, è stato aggiunto CLR 4.0 ma CLR 2.0 era ancora l'impostazione predefinita.

A partire da Mono 2.8, CLR 4.0 è diventato il valore predefinito e CLR 1.1 non è più supportato.

Mono 2.10 continua a utilizzare CLR 4.0 come predefinito e anche a supportare CLR 2.0.

Proprio come il vero .NET (ma in molti meno casi) ci sono alcuni assembly Mono che richiamano nelle librerie native. Per far funzionare l'assembly System.Drawing su Mono, il team Mono ha scritto un programma Linux per simulare la parte GDI + dell'API Win32 su Linux. Questa libreria si chiama 'libgdiplus'. Se compili Mono dal sorgente, noterai che devi creare questo file 'libgdiplus' prima di poter costruire 'mono'. Non è necessario 'libgdiplus' su Windows perché la parte GDI + dell'API Win32 fa già parte di Windows. Un port completo di Mono su nuove piattaforme richiede il porting anche di questa libreria "libgdiplus".

Nelle aree in cui il design della libreria .NET è eccessivamente influenzato dal design di Windows e inadeguato per sistemi come Mac o Linux, il team Mono ha scritto estensioni al framework .NET. Le estensioni Mono sono anche solo bytecode CIL e generalmente funzionano bene su .NET.

A differenza di Windows, Linux generalmente non rileva eseguibili .NET e avvia il CLR per impostazione predefinita. In genere l'utente deve eseguire direttamente il CLR digitando "mono appname.exe" o qualcosa di simile. Qui "mono" è l'applicazione che implementa il CLR e "appname.exe" è il file EXE che contiene il codice .NET da eseguire.

Per rendere le cose più facili per gli utenti, le applicazioni Mono sono spesso racchiuse in uno script shell che avvia CLR. Ciò nasconde il fatto che il CLR viene utilizzato proprio come in Windows. È anche possibile dire a Linux di avviare CLR quando viene rilevato un file che utilizza il formato di file PE. Questo di solito non viene fatto poiché il formato file PE viene utilizzato anche per eseguibili Windows nativi Win32 che ovviamente il CLR (Mono) non supporta.

Non vi è alcun motivo tecnico per cui un launcher PE non possa essere utilizzato da Linux, che quindi avvia un sistema che comprende il codice nativo di Windows (come Wine) o il CLR (Mono) come appropriato. Questo semplicemente non è stato fatto per quanto ne so.

Avanti e indietro

Qualsiasi codice .NET che si attenga a " completamente gestito " code, il che significa che non chiama in un codice non.NET, dovrebbe funzionare bene su Mono su tutte le piattaforme. Uso abitualmente assembly .NET compilati da Windows (per i quali non ho il codice) su Linux e Mac.

Posso anche prendere qualsiasi codice che compilo su Mono ed eseguirlo su .NET su Windows. Posso fornire ad un client un codice che ho compilato con Mono e non preoccuparmi se, ad esempio, si trova su Windows a 32 o 64 bit. È necessario che il client abbia installato la versione corretta di .NET (il CLR giusto). CLR 2.0 è in circolazione da molto tempo e puoi scommettere che quasi tutti gli utenti Windows lo hanno installato. I compilatori Mono e altri codici sono anche solo eseguibili CIL e quindi funzionano bene su Windows, se lo desideri.

La compatibilità mono è abbastanza buona da poter prelevare grandi blocchi di codice Microsoft effettivo, come ASP.NET MVC (laddove legale farlo) dall'attuale versione MS di .NET ed eseguirli su Mac o Linux. In generale, il team Mono ha fatto un ottimo lavoro nell'implementare sia il CLR che il resto del framework (librerie di classi / assiemi).

ASP.NET

Su Windows, Internet Information Server (IIS) sa come chiamare nel CLR per eseguire .NET come parte di un'applicazione web. Su Linux / Mac esiste un modulo Apache (mod_mono) che fornisce funzionalità simili al server web Apache. Questa applicazione è scritta in C e deve anche essere trasferita su nuove architetture.

Porting Mono

Questa discussione ha identificato parti di Mono che sono costruite come "native" eseguibili e devono esistere su un sistema su cui si desidera eseguire applicazioni .NET.

  • CLR (incluso il compilatore JIT), generalmente noto come Mono
  • libgdiplus (per sistemi che non supportano nativamente l'API GDI + [solo Windows]]
  • mod_mono (per consentire ad Apache di invocare il CLR per le applicazioni web .NET)

Questi tre componenti, con l'aggiunta delle librerie di classi, forniscono un ambiente .NET che sembra "nativo" ai file eseguibili .NET che è necessario eseguire.

Ecco come funziona Mono.

È infatti possibile eseguire un file .exe .NET con Mono su Linux. Questo non richiede vino. Infatti, Mono compila i programmi in file .exe, che possono essere eseguiti sia con Mono su Linux sia come eseguibile su Windows.

Mono è un'implementazione open source di Microsofts .NET CLR (Common Language Runtime). Questo è ciò che esegue parte dei programmi .NET che non sono in codice nativo ma in CIL (Common Intermediate Language), una lingua e una lingua intermedia neutra dalla macchina. Il runtime prende quel codice intermedio e lo traduce in codice macchina.

Allo stato attuale di Mono, puoi prendere i programmi .NET che usano le parti principali di .NET (mscorlib.dll) ed eseguirli ovunque venga eseguito Mono, non solo Windows.

Ma poiché si dice che Mono è open source e non si può semplicemente fare affidamento sul fatto che sarà l'implementazione completa di .NET, ha alcuni controlli che non funzionano, è necessario anche fare attenzione con P / Invokes che il proprio l'applicazione utilizzerà, ad esempio l'applicazione comunicherà con MCI (Multimedia Controller Interface) sotto win32. Ma stavo usando anche le applicazioni GTK # per la scrittura mono, ma ho anche usato le mie applicazioni Windows che funzionavano senza alcuna ricompilazione, come menzionato sopra i nostri colleghi programmatori, ovvero mono è un'alternativa open source di .NET di Microsoft, e per impostazione predefinita se stai creando applicazioni WinForms o Gtk # mono compilerà e creerà un assembly .exe per ogni file, e ovviamente se lo desideri creerai una Dynamic Link Library (DLL), quasi come avviene in .NET. Solo per un suggerimento prova a scrivere un po 'di Gtk # (con MonoDevelop IDE che ha il suo designer di gui integrato chiamato stetic). E ovviamente mono può essere un ottimo sostituto per i servizi Web che puoi crearli su .NET e puoi ospitarli su Apache (perché l'hosting Linux al giorno d'oggi è più economico di quelli Windows) i servizi web e altre app asp.net funzioneranno sotto apache con un modulo mod_mono che deve essere incluso in apache.

Un po 'fuori tema, ma volevo solo raccontarvi un'anteprima della mia esperienza.

Inoltre puoi dare un'occhiata al MoMA (se il tuo obiettivo è portare le applicazioni da Win a Lin).

  

The Mono Migration Analyzer (MoMA)   lo strumento ti aiuta a identificare i problemi che potresti avere   quando effettui il porting del tuo .Net   applicazione a Mono. Aiuta a individuare   chiamate specifiche della piattaforma (P / Invoke) e   aree che non sono ancora supportate da   il progetto Mono.

MoMA

Ecco una webapp che confronta i tipi di BCL già implementati da Mono e .NET Framework 3.5

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

Per favorire la risposta di Michael, credo che dovrai ricompilare su Mono affinché l'app venga eseguita sul runtime Mono. Possono esistere eccezioni. Ho solo giocato un po 'con Mono, e ho sempre ri-compilato il sorgente. Non ho mai provato a eseguire un'app .NET direttamente su Mono.

Inoltre, Mono 1.9 dovrebbe essere completamente conforme a .NET 2.0. Mono Olive e Moonlight dovrebbero aggiungere .NET 3.0 (meno WPF) e funzionalità Silverlight.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top