Dove si trova esattamente .NET Runtime (CLR), Compilatore JIT?

Question

Questa domanda potrebbe sembrare un po 'folle o strana, ma ho sentito parlare molto di .NET CLR, compilatore JIT e di come funziona blah blah blah ... Ma ora mi chiedo dove si trova esattamente o ospitato.

è -

• Hosted come parte del sistema operativo di Windows quando abbiamo effettivamente Installare .NET Framework?

O

• è una parte di qualche .exe che possiamo vedere nel task manager

Sto cercando la risposta dettagliata su questo. Qualcuno potrebbe inquadrare questa domanda: "Come fa scattare i sistemi operativi Windows/esegue .NET eseguibile all'interno di .NET Runtime?

Answer 1

esattamente dove si trova o ospitato

E 'solo una DLL pianura, troverete di nuovo la versione x86 di esso in C: \ Windows \ Microsoft.NET \ Framework \ v4. 0,30,319 mila \ clrjit.dll. La versione x64 si trova nella directory Framework64. La versione .NET v2 aveva un nome diverso, mscorjit.dll, lo trova nelle directory v2.0.50727.

Non è "ospitato" affatto, il sistema operativo è completamente inconsapevole dell'esistenza. Il CLR sa come individuarlo e caricarlo. Necessariamente così, è il CLR che decide quando avviare un programma. Semplicemente ha il nome della DLL hard-coded e usa LoadLibrary ("clrjit.dll") per caricarlo, GetProcAddress ("getJit") per ottenere la funzione di fabbrica. Qualcosa che puoi vedere nel codice sorgente di CoreCLR, anche se il jitter non è più una DLL separata in quella versione CLR.

È possibile visualizzare anche il CLR con Explorer, ancora una semplice DLL. È clr.dll nelle versioni v4, mscorwks.dll e mscorsvc.dll nelle versioni v2. Due diversi allora con diversi garbage collector, "wks" è la versione della workstation, "svc" è la versione del server. Confrontare con la voce del file di configurazione <gcServer>.

Che sposta la domanda su "come viene caricato il CLR?" Questo è il lavoro di c: \ windows \ syswow64 \ mscoree.dll, verrà utilizzato c: \ windows \ system32 \ mscoree.dll quando si target x64 nel progetto EXE. Ogni assembly .NET ha 5 o 9 byte di codice non gestito, un salto in quella DLL. O _CorExeMain o _CorDllMain, a seconda che l'assembly sia stato creato come un exe o una libreria. mscoree.dll dà un'occhiata ai metadati nell'assembly e decide quale versione del CLR deve essere caricata in modo che possa essere eseguita correttamente.

Un sacco di altri imbrogli in corso, ho appena pubblicato la vista di 10.000 piedi che hai chiesto. Se questo ti interessa allora probabilmente vorresti saperne di più su custom CLR hosting per vedere l'uomo dietro la tenda.

Answer 2

Come sistema operativo Windows innesca/esegue .NET eseguibile Esegue all'interno di .NET Runtime?

Ogni assembly o eseguibile gestito .NET dispone di intestazioni CLR speciali, che è possibile visualizzare visualizzando l'assembly in ILDASM, che punta alla versione del runtime che deve essere caricata.Inoltre, c'è la Sezione Immagine con lo Import Address Table, indicando ciò che deve essere caricato:

----- Image sections: 
Import Address Table 
DLL : mscoree.dll 
      0x00002000 Import Address Table 
      0x0000a37e Import Name Table 
      0   Time Date Stamp 
      0   Index of First Forwarder Reference 

      0x0000 _CorDllMain 

----- CLR Header: 
Header size:      0x00000048 
Major runtime version:    0x0002 
Minor runtime version:    0x0005 
0x00003184 [0x00007078] address [size] of Metadata Directory:   
Flags:        0x00000001 
Entry point token:     0x00000000 
0x00000000 [0x00000000] address [size] of Resources Directory:  
0x00000000 [0x00000000] address [size] of Strong Name Signature:  
0x00000000 [0x00000000] address [size] of CodeManager Table:   
0x00000000 [0x00000000] address [size] of VTableFixups Directory:  
0x00000000 [0x00000000] address [size] of Export Address Table:  
0x00000000 [0x00000000] address [size] of Precompile Header: 

Quando riceve dal sistema operativo, mscoree.dll (o lo spessore) è caricato, ed è l'avvio automatico di clr.dll e clrjit.dll NET 4.0 e superiore, oppure mscordacwks.dll e mscorjit.dll NET 2.0 o inferiore, che sono il runtime e il JIT, rispettivamente. È possibile vedere che il punto di ingresso della DLL nativa viene indicato come metodo _CorDllMain per una libreria di classi e _CorExeMain per un file eseguibile, che è responsabile del caricamento e della jitting del punto di ingresso. A loro volta, chiameranno il punto di ingresso delle applicazioni, nell'ambiente gestito.

Answer 3

Questo è basato sulla mia comprensione e ti guiderà verso la tua risposta, ma potrebbe non essere completamente cancellato.

I file/DLL EXE che compongono la DotNet Runtime (CLR, ecc) si trovano nelle seguenti posizioni:

C:\Windows\Microsoft.NET\Framework // for the 32 bit runtime 
C:\Windows\Microsoft.NET\Framework64 // for the 64 bit runtime 

All'interno lì, si hanno le diverse edizioni come 2.0.50727, 3,0 , 3.5 e 4.0.30319 (versioni sul mio sistema oggi).

Qui MSBuild e i file registrati con IIS vengono individuati ed eseguiti.

Non so se questo finisce per essere ospitato da Windows in fase di esecuzione, o se c'è un vero e proprio EXE che si può collegare a un debugger e vedere nel task manager.

Speriamo che questo fornisca ulteriori informazioni per voi.