2010-02-17 16 views
8

Come determinare se le immagini native vengono utilizzate senza che il programma di caricamento verifichi la firma dell'assembly in fase di runtime o addirittura utilizzi l'assembly GAC?Determinare se vengono utilizzati gli assembly di GAC e NGen

Ho un sistema complesso che stiamo sperimentando con NGen ma attualmente stiamo eseguendo l'exe dalla cartella in cui si trovano tutte le DLL a causa di molte dipendenze di binding tardive, guardando Process Explorer, sembra che il Le immagini native vengono utilizzate, ma come posso essere sicuro di ottenere tutti i vantaggi e di eliminare la fase di verifica del caricatore?

Cheers, Graeme.

Aggiornamento: sto ricevendo un sacco di questo genere di cose dall'Assemblea Binding spettatore Log:

LOG: [Level 1]Start validating IL dependency MyCompany.Entities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd. 
LOG: Dependency evaluation succeeded. 

e alla fine

LOG: Validation of dependencies succeeded. 
LOG: Start loading all the dependencies into load context. 
LOG: Loading of dependencies succeeded. 
LOG: Bind to native image succeeded. 
Native image has correct version information. 
Attempting to use native image C:\Windows\assembly\NativeImages_v2.0.50727_32\MyCompany.Mylibrary#\4710bb8309419d707681bd360088181f\MyCompany.MyLibrary.MyClass.ni.dll. 
ZAP: Native image has been relocated. 
Native image successfully used. 

quindi è usando le immagini native ma ancora verificandoli, cioè non usando la versione GAC anche se è da lì che ho creato l'immagine nativa, così:

ngen install "MyCompany.Entites, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd, processorArchitecture=MSIL" 

Nota: Questo articolo sembra implicare che se gli assembly non vengono caricati dal GAC, il processo di verifica compenserà i vantaggi NGen? CLR Inside Out - Improving Application Startup Performance (MSDN)

Aggiornamento - Come Nobugz ha sottolineato in un commento qui sotto, la fase di verifica di cui sopra non viene effettuato dal 3.5 SP1 vedere: MSDN Docs on NGen

risposta

11

Si può facilmente vederlo dallo strumento Fuslogvw.exe. Avvia dal Prompt dei comandi di Visual Studio. Configura con Categorie di registro = Immagini native, Impostazioni + Registra tutti i collegamenti su disco. Esegui il tuo programma. Torna a fuslogvw, Aggiorna. Ti mostrerà una lista di tutti gli assembly che sono stati caricati.

Fare doppio clic su una voce per vedere come è stato caricato l'assieme. Se ne è venuto dal GAC, si vedrà:

LOG: L'assemblaggio caricato da C: \ Windows \ assembly \ GAC_MSIL \ blahblah

Se le immagini Ngen-ed è stato utilizzato, è 'll see:

LOG: associazione a immagine nativa riuscita.

+0

+1 questo sembra promettente, ma penso che sta dimostrando che le mie immagini native vengono utilizzate non dal GAC, quindi sono ancora convalidate dal caricamento, compensando in modo efficace il vantaggio di ngen, vedere le mie modifiche all'originale Q. –

+1

@dog - Mi sembra chiaro, l'assembly non viene caricato dal GAC, ma utilizza l'immagine Ngen-ed. E 'normale. Non sei sicuro di quale altro problema ci possa essere, la validazione del nome forte viene saltata in piena fiducia se è questo che ti preoccupa. –

+0

Ho aggiunto una nota a piè di pagina, è la verifica del caricatore a cui si fa riferimento in quell'articolo che sto cercando di eliminare. –

1

Si può vedere se il gruppo è venuto dal GAC abbastanza facilmente :

Assembly assembly = Assembly.GetExecutingAssembly(); 

if (assembly.GlobalAssemblyCache) 
{ 
    Console.WriteLine("I'm in the GAC!"); 
} 

EDIT: trovato un modo ...

Per verificare se è NGEN, è necessario leggere direttamente l'assembly e verificare se il campo Precompile Header contiene dati come this page. Sono un po 'arrugginito per arrivare a quel valore, ma dovrebbe farlo. Non vedo il modo di capirlo attraverso i metodi di riflessione.

+2

Sono in grado di determinare se NGen è in grado di esaminare il riquadro di visualizzazione della DLL in Process Explorer, passando con il mouse sopra il nome fornisce il percorso completo come ... c: \ Windows \ Assembly \ NativeImages_v2.0.5072_32 \ MyDll.ni .dll –

+0

Aggiunto qualcosa di un indizio per la mia risposta. –

+0

Motivo del downvote downvoter? –

0

È possibile utilizzare VMMAP. Lì, tutti i .dll (assembly) hanno dettagli sulla posizione

In dettaglio se l'assembly viene caricato da "C: \ Windows \ assembly \ NativeImages (versione) ..." in modo che l'applicazione utilizzi l'immagine nativa.

Problemi correlati