Numero di istanze CLR e GC in esecuzione su una macchina?

Question

Creo 2 applicazioni .NET e le eseguo su una macchina: quanti CLR e gc ci saranno?

Inoltre: mi piacerebbe avere alcune informazioni di base su come Windows gestisce i componenti COM e CLR in particolare. La speranza qualcuno potrebbe dettaglio fino al modo in cui i carichi di memoria e quello CLR vuol dire se ho più istanze CLR quotate in esecuzione di questo comando:

tasklist /m mscor* 

E 'più CLR in atto o una sola CLR come server COM per tutti. Processi NET?

Answer 1

Ogni processo avrà una propria copia del CLR come processo di hosting. Tuttavia, poiché il CLR è in realtà solo un paio di DLL, Windows sarà in grado di condividere le DLL tra i processi. Per ulteriori informazioni vedere: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx

Answer 2

CLR è in realtà il componente che trasforma MSIL nel codice macchina nativo. Questo codice macchina nativo viene quindi eseguito nel proprio processo per ogni applicazione.

E nel mondo .NET un processo è strettamente correlato a un appdomain. Ecco perché penso che this sia un buon punto di partenza.

Answer 3

Direi che puoi facilmente contare i processi che eseguono o caricano il CLR controllando le DLL caricate. Ma non sono sicuro di poter contare il numero di domini dell'applicazione in esecuzione. Ma non penso che questo sia il tuo obiettivo.

C'è solo un heap per processo e anche un GC, che sospende tutti i thread gestiti durante la raccolta. Quindi è possibile scorrere i processi e verificare se mscorlib è caricato, in tal caso si può presumere che sia in esecuzione un CLR .NET e un GC. Sono sicuro che ci dovrebbero essere modi migliori per determinare se un processo ha CLR ospitato, per favore controlla anche l'API CLR.

Si prega di provare il libro di Jeffrey Richter CLR via C# per avere una comprensione più approfondita.

Il seguente codice itera NET elabora

// Import these namespaces 
using System.Diagnostics; 
using System.ComponentModel; 

// Here is the code 
Process[] prcs = Process.GetProcesses(); 
foreach (Process prc in prcs) 
{ 
    try 
    { 
     foreach (ProcessModule pm in prc.Modules) 
     { 
      if (pm.ModuleName.Contains("mscorlib")) 
      { 
       Console.WriteLine(prc.ProcessName); 
      } 
     } 
    } 
    catch (Win32Exception exWin) 
    { 
     // Cannot detemine process modules ... some will deny access 
    } 
} 

Answer 4

Un gestiti exe ha un ulteriore CLR intestazione un'aggiunta alla Portable Executable (PE format). Il sistema operativo ora è in grado di determinare se l'exe lanciato è un exe "gestito" e quindi carica il CLR dietro le quinte e gli dà il controllo.

• mscoree.dll è una DLL spessore (l'ultima versione di questo file è sempre presente nella cartella Windows/System32 e quindi sa come caricare le versioni attuali e precedenti del CLR.)
• mscorwks.dll è l'effettiva implementazione del CLR. Troverai più versioni di questa dll se hai installato più versioni del framework. La versione corretta di questa dll è caricata dallo shim dll.

Da quanto precede deriva che ogni processo di eseguibile gestito avrebbe una propria copia del CLR (2 DLL). ManagedExecutable1 può utilizzare CLR v1 dove come ManagedExecutable2 può utilizzare CLR v2. Non sono condivisi sin d'ora.
Il Garbage Collector fa parte del CLR e quindi è anche distinto tra i processi per i file eseguibili gestiti.