Sono confuso con MSIL e Codice gestito sono uguali o diversi? Intendo dire, cosa succede quando abbiamo creato il nostro codice C#?MSIL è uguale al codice gestito in .NET?
quale è giusto
C# Code → C# compiler → Managed Code → MSIL
o
C# Code → C# compiler → MSIL
Si prega di fornire un riferimento autentico o un link a sostegno della tua risposta.
Come indicato nei commenti, MSIL è stato rinominato in CIL.
C# Code --> C# compiler --> CIL
perché
CIL = Managed
Quando si inserisce nel suo contesto, c'è anche
Native Code = Unmanaged
noti che Managed Code è qualcosa di completamente diverso, che refers to the source code.
Se si desidera estendere, quindi l'intero processo corretto è:
.NET Code --Compiler--> CIL (Managed) --JIT/NGEN--> Native Code (Unmanaged)
Riferimenti:
Il codice scritto per funzionare esclusivamente sotto il controllo del CLR è chiamato codice gestito. (Source). Così
C# Codice → compilatore C# → CIL (precedentemente noto come MSIL)
è corretto.
Grazie per il riferimento. Puoi appuntare il punto nel documento che lo chiarisce? –
@ user129967 Prima sezione, "Il ruolo del CLR", terzo paragrafo. Puoi anche premere Ctrl + F e cercare l'articolo per "codice gestito". – Indrek
Stai confondendo cose diverse. Managed code è un codice scritto in un linguaggio gestito (C#, VB.NET, F # e molti altri) che è compilato in CIL (Common Intermediate Language, precedentemente Microsoft Intermediate Language o MSIL) ed eseguito nell'ambiente gestito di CLR.
Il codice non gestito, d'altra parte è compilato direttamente nel codice nativo (chiamato anche assembly), non viene eseguito su CLR.
Quando si genera il codice C#, viene compilato in CIL. Questo è il motivo per cui puoi usare strumenti come ildasm o Reflector per ispezionare il codice compilato. Ciò che accade esattamente quando si esegue il codice CIL dipende dalle circostanze. Potrebbe essere
+1 per andare oltre la domanda. L'OP dovrebbe anche leggere alcuni articoli introduttivi di tipo "Panoramica di .NET" per comprendere meglio gestito e non gestito. Eccone uno: http://www.codeproject.com/Articles/7333/Understanding-NET-Framework-at-a-ance –
C# è "gestito" solo se NON stai usando la parola chiave "non sicura". –
Quindi C# e CIL sono entrambi gestiti o solo uno di loro? –
Quando si scrivono programmi per Windows, è possibile scrivere uno dei due tipi di codice: gestito e nativo. Il codice nativo viene compilato direttamente in un eseguibile o dll della macchina, mentre il codice gestito è il codice destinato al runtime .NET (in altre parole, il suo modulo compilato, definito un assembly, è un file contenente istruzioni CIL). In fase di runtime, il CIL viene convertito in codice macchina dal compilatore JIT ed eseguito. La differenza tra gestito e nativo ha a che fare con ciò che il linguaggio (e il suo compilatore) prende di mira. Il codice nativo ha come target la macchina stessa perché è compilato in un insieme di istruzioni dirette della macchina. D'altra parte, i compilatori C# compilano il codice in CIL perché il compilatore di linguaggio C# ha come obiettivo il runtime .NET. Si può quindi dire che C# è un "linguaggio gestito" e qualsiasi codice scritto in esso è "codice gestito". Ad esempio:
C src -> gcc.exe -> .exe containing a machine binary -> processor
C# src -> csc.exe -> .exe assembly containing CIL -> CLR/JIT -> processor
Credo che la ragione il termine "free" è utilizzato è perché le istruzioni che formano il suo codice sono infine gestite dal runtime NET invece di essere eseguite direttamente dal processore. Il passaggio extra di compilazione del codice sorgente in CIL non è di per sé ciò che rende il codice gestito: piuttosto, il fatto che il tuo programma non venga mai eseguito direttamente dal processore. Il CIL è proprio ciò che consente a più linguaggi gestiti di mirare allo stesso runtime.
So che questo è molto più complesso del semplice dire "lingue gestite compila in CIL", ma questo perché non penso che sia una descrizione completamente accurata di ciò che rende il codice gestito. Il bytecode Java è analogo a CIL, ma esistono veri "processori Java" che possono eseguire in modo nativo bytecode. Un tale processore è concepibile anche per .NET CIL, il che significa che il codice compilato in CIL ed eseguito su tale macchina diventerebbe nativo. Il fatto che il tuo codice debba essere gestito attraverso il CLR è ciò che lo rende gestito. Il CIL è il formato in cui il codice deve essere convertito in modo che il runtime possa eseguirlo.
Questo è molto vicino, ma ciò che lo rende gestito o meno è il livello di sicurezza che esegue la garbage collection e previene gli overflow del buffer di runtime e cosa no. Quindi perché i termini "non sicuri" si applicano quando si esegue il codice nativo dal codice gestito. Non si tratta di "non eseguire direttamente dal processore", perché viene eseguito direttamente, ma solo che il codice è verificato e avvolto in livelli di sicurezza di runtime. –
Qui non entrerò molto nei dettagli, perché altri ne hanno già parlato molto, ma voglio chiarire alcuni punti che altre risposte non hanno spiegato bene o correttamente. Questo è in gran parte pedante, e per il 99,9999% dei casi si può solo pensare a "C# e CIL/MSIL è il codice gestito", ma ci sono alcune sottigliezze a questo.
In primo luogo, CIL/MSIL è noto come "linguaggio intermedio", il che significa che si tratta di un linguaggio di computer che viene utilizzato come passaggio intermedio tra il codice sorgente e il codice macchina finale nativo. Tuttavia, questo non è necessario essere il caso. Ho sentito parlare di progetti sperimentali in cui hanno creato una CPU che esegue CIL (o l'equivalente java chiamato Java Byte Code) direttamente senza prima convertirlo in una forma nativa (in pratica, il CIL è la forma nativa).
Il codice gestito fa riferimento al codice "gestito" da un runtime gestito di qualche tipo. Ciò significa in genere che il codice viene raccolto e ha una sorta di livello di sicurezza che impedisce cose come buffer overflow e altri tipi di problemi che possono verificarsi nel codice nativo. In .net questo è noto come Common Language Runtime (CLR)
In passato, questo era noto come "macchina virtuale" e perché l'ambiente java è chiamato JVM, anche se questo termine è ora in gran parte un termine improprio. Oggigiorno, con i compilatori JIT (Just in time), non esiste una "macchina virtuale", ma è invece un livello di codice che "avvolge" il codice compilato nativo per assicurare che non si infrangono le regole e per ripulire dopo il tuo codice. Inoltre, astrae alcune delle cose specifiche della piattaforma in modo che il CIL non debba preoccuparsi di loro.
Quindi, il codice gestito fa riferimento al concetto di codice in esecuzione in un runtime gestito. CIL è considerato codice gestito quando è in esecuzione in un runtime come l'ambiente di runtime .NET.
C# e VB.NET sono spesso considerati "lingue gestite" perché in genere vengono compilati in CIL ed eseguiti in un runtime gestito. Tuttavia, questo non deve necessariamente essere il caso (anche se seguendo la lettera della specifica, probabilmente deve essere il caso). Per esempio, ci sono compilatori che compilano C# direttamente al codice nativo senza un livello intermedio, e ci sono interpreti di runtime per C# che non compilano affatto il codice, ma piuttosto lo "interpretano" in fase di runtime.
Quindi l'essenza è che il codice gestito e CIL sono due cose diverse, ma sono correlate.
E viene ufficialmente chiamato CIL, Common Intermediate Language, come da [ECMA] (http://www.ecma-international.org/publications/standards/Ecma-335.htm) – Bob
NGEN di solito è ** non ** usato quando si compila in codice nativo, viene usato invece il compilatore JIT. E "[byte code] (http://en.wikipedia.org/wiki/Bytecode)" è ** non ** un altro nome per il codice nativo, è un altro nome per il codice gestito. – svick
In effetti, ha menzionato anche JIT e ora ha deciso di usare "native" per evitare confusione. –