2010-05-07 10 views
17

Consideriamo l'applicazione .NET Winforms o l'applicazione console. Qualcuno può dirmi cosa succederà passo dopo passo fino a quando non verrà lanciata l'applicazione WinForm o Console. Mi piacerebbe conoscere gli interni - come il modo in cui EXE comunicherà con Framework, qual è il ruolo di CLR, cosa succede in caso di eccezione durante l'avvio dell'applicazione stessa.etc ...Cosa succede quando l'utente fa clic su .NET assembly (EXE)?

+6

Come risposta stakoverflow? Ci sono libri scritti a riguardo di centinaia di pagine;) – TomTom

+5

@TomTom - Non è molto giusto! ... quelle sono le versioni abbreviate. –

+2

1. Scarica Mono. 2. Compilalo. 3. Avvia da un debugger. 4. Passo singolo. 5. Ripeti il ​​passaggio 4. –

risposta

13

Facendo doppio clicca su un gruppo .exe .net:

  • calci PE loader di Windows' in
  • Se siete su un Windows> = Windows XP rileverà che l'eseguibile è un eseguibile gestito e la trasmetterà al .net chiamando _CoreExeMain in mscoree.dll (_CoreDllMain se si fa doppio clic su un .dll gestito). Può utilizzare il file di configurazione dell'assembly per sapere quale runtime utilizzare.
  • Se sei su Windows < Windows XP, il file .exe contiene una piccola parte nativa di codice che salterà a mscoree.dll _CoreExeMain o _CoreDllMain.
  • Quindi mscoree.dll inizializza il runtime .net, a seconda della configurazione globale, del file di configurazione dell'assieme e di cosa no.
  • Quindi, se è un .exe, JIT compilerà il metodo del punto di ingresso e inizierà a eseguirlo.
+0

Questo è fantastico. Grazie per la tua risposta Jb Evain! – Sathish

1

Il MSCoreEE.dll (mscore Esecuzione Engine.Dll sola istanza per una macchina) Say per esempio quando un gruppo Net/exe si fa doppio click o avviate, il sistema operativo caricherà il caricatore Windows che Inturn carica l'header PE (Portable executable) [nel caso di eseguibile win32, l'header PE conterrà l'indirizzo del bootstrap (Main() statico da dove verrà caricato ed eseguirà il metodo main, dove come .Net, il bootstrap conterrà l'indirizzo di MSCoreEE.Dll che sarà presente in C: \ Windows \ System32 \ mscoree.dll che verrà eseguito e caricherà il runtime .Net per il quale è stato scelto l'assembly .net. Ci possono essere più versioni di. Runtime installato sulla macchina, tuttavia, ci sarà solo una istanza di mscoreee.dll per caricare i runtime specifici.

Il CLR creerà il primo dominio applicazione stessa e caricare l'assembly (se l'assemblea non ha creato domini app supplementari in codice)

Il CLR crea 3 domini applicazione internamente 1. Sistema App Dominio un .  è responsabile del caricamento dei domini applicazione condivisi e predefiniti, carica anche mscorelib.dll nel dominio dell'app condivisa b.  Crea 3 istanze separate di Eccezioni i. Eccezione fatale del motore ii. Eccezione di overflow dello stack iii. Eccezione di memoria insufficiente (molto importante, il CLR preclude l'eccezione "fuori memoria" bcose quando lo sviluppatore pensa che l'applicazione possa uscire dalla memoria e voglia scrivere l'eccezione su un file di registro, la creazione dell'eccezione di memoria avrà luogo perché c'era nessuna memoria rimasta per creare una nuova istanza di questa eccezione, quindi CLR precorre questa eccezione per l'utilizzo futuro nell'applicazione 2. Dominio app condivisa a. Contiene mscorlib.dll b.Altre librerie comuni utilizzate da altri domini delle app c. Tuttavia, lo sviluppatore non può spingere i Dll personalizzati nel dominio dell'app condivisa in quanto non controllabile da CLR, gli host CLR non possono essere controllati da dll e CLR stessi come è ospitato da uno sviluppatore, tuttavia è possibile utilizzare alcune interfacce COM dove lo sviluppatore può ospitare il CLR consueto 3. Dominio app predefinito a. Tutti i file binari dell'utente .exe, Dll viene caricato qui

Problemi correlati