Generatore di immagini native (Ngen.exe)

Il generatore di immagini native (Ngen.exe) consente di migliorare le prestazioni delle applicazioni gestite. Questo strumento crea immagini native, ovvero file contenenti codice in linguaggio macchina compilato specifico del processore, e le installa nella cache delle immagini native del computer locale. Common Language Runtime può utilizzare le immagini native nella cache anziché utilizzare il compilatore JIT per compilare l'assembly originale.

Ngen.exe ha subito modifiche sostanziali in .NET Framework versione 2.0:

• Insieme a un assembly vengono installate anche le relative dipendenze. In questo modo la sintassi di Ngen.exe risulta semplificata.

• È ora possibile condividere le immagini native in più domini applicazione.

• È ora disponibile una nuova azione, update, che consente di ricreare le immagini invalidate.

• È possibile rinviare l'esecuzione delle azioni mediante un servizio che utilizza il tempo di inattività sul computer per generare e installare le immagini.

• Alcune cause dell'invalidazione delle immagini sono state eliminate.

Per ulteriori informazioni sull'utilizzo di Ngen.exe e del servizio immagini native, vedere Servizio immagini native.

Nota

Per la sintassi di Ngen.exe per le versioni 1.0 e 1.1 di .NET Framework, vedere Sintassi preesistente del generatore di immagini native (Ngen.exe).

ngen <action> [options]
ngen /? | /help

Azioni

Nella tabella riportata di seguito viene illustrata la sintassi di ciascuna azione. Per le descrizioni delle singole parti di actionArguments, vedere le tabelle Argomenti, Scenari e Configurazione. Nella tabella Opzioni vengono descritte le options e le opzioni della Guida in linea.

Azione	Descrizione
install [assemblyName | assemblyPath] [scenarios] [config] [/queue[:{1|2|3}]]	Genera le immagini native per un assembly e le relative dipendenze e le installa nella cache delle immagini native. Se si specifica l'opzione /queue, l'azione viene accodata per il servizio immagini native. La priorità predefinita è 3.
uninstall [assemblyName | assemblyPath | *] [scenarios] [config]	Elimina le immagini native di un assembly e delle relative dipendenze dalla cache delle immagini native. Per disinstallare una singola immagine e le relative dipendenze, ricorrere agli stessi argomenti della riga di comando utilizzati per l'installazione dell'immagine.
update [/queue]	Aggiorna le immagini native non valide. Se si specifica l'opzione /queue, gli aggiornamenti vengono accodati per il servizio immagini native. Gli aggiornamenti vengono sempre pianificati con priorità 3, in modo da essere eseguiti durante i periodi di inattività del computer.
display [assemblyName | assemblyPath]	Visualizza lo stato delle immagini native per un assembly e le relative dipendenze. Se non viene fornito alcun argomento, verrà visualizzato l'intero contenuto della cache delle immagini native.
executeQueuedItems [1|2|3]	Esegue i processi di compilazione accodati. Se è specificata una priorità, verranno eseguiti soltanto i processi di compilazione che hanno un livello di priorità maggiore o uguale a quello specificato. Se non è specificata alcuna priorità, verranno eseguiti tutti i processi di compilazione accodati.
queue {pause | continue | status}	Consente di sospendere il servizio immagini native, di riprendere il servizio sospeso o di determinare lo stato del servizio.

Argomenti

Argomento	Descrizione
assemblyName	Nome dell'assembly. È possibile fornire un nome di assembly parziale, ad esempio myAssembly, o un nome completo, ad esempio myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5. È possibile specificare un solo assembly per ogni riga di comando di Ngen.exe.
assemblyPath	Percorso esplicito dell'assembly. È possibile specificare un percorso completo o relativo. Se si specifica un nome di file senza percorso, l'assembly deve trovarsi nella directory corrente. È possibile specificare un solo assembly per ogni riga di comando di Ngen.exe.

Scenari

Scenario	Descrizione
/Debug	Genera immagini native utilizzabili mediante un debugger.
/Profile	Genera immagini native utilizzabili mediante un profiler.
/NoDependencies	Genera il numero minimo di immagini native richiesto dalle opzioni dello scenario specificato.

Configurazione

Configurazione	Descrizione
/ExeConfig: exePath	Utilizza la configurazione dell'assembly eseguibile specificato. Al momento dell'associazione alle dipendenze, le decisioni di Ngen.exe devono coincidere con quelle effettuate dal caricatore. Quando un componente condiviso viene caricato in fase di esecuzione, mediante il metodo Load, il file di configurazione dell'applicazione determina le dipendenze che devono essere caricate per il componente condiviso, ad esempio la versione di una dipendenza caricata. L'opzione /ExeConfig indica a Ngen.exe le dipendenze che verranno caricate in fase di esecuzione.
/AppBase: directoryPath	Al momento dell'individuazione delle dipendenze, la directory specificata verrà utilizzata come base dell'applicazione.

Opzioni

Opzione	Descrizione
/nologo	Evita la visualizzazione del messaggio di avvio Microsoft.
/silent	Evita la visualizzazione dei messaggi di operazione riuscita.
/verbose	Visualizza informazioni dettagliate per il debug. Nota A causa delle limitazioni del sistema operativo, in Windows 98 e Windows Millennium Edition verranno visualizzate una quantità ridotta di informazioni aggiuntive.
/help, /?	Visualizza la sintassi del comando e le opzioni della versione corrente.

Note

Per eseguire Ngen.exe, è necessario disporre di privilegi amministrativi.

Ngen.exe genera immagini native per l'assembly specificato e tutte le relative dipendenze. Le dipendenze vengono determinate dai riferimenti presenti nel manifesto dell'assembly. L'unico scenario in cui è necessario installare separatamente una dipendenza si verifica quando l'applicazione ne esegue il caricamento tramite reflection, ad esempio chiamando il metodo System.Reflection.Assembly.Load.

Importante
Non utilizzare il metodo System.Reflection.Assembly.LoadFrom con le immagini native. Un'immagine caricata con questo metodo non può essere utilizzata da altri assembly nel contesto di esecuzione.

Lo strumento Ngen.exe gestisce un conteggio delle dipendenze. Si supponga, ad esempio, che MyAssembly.exe e YourAssembly.exe siano installati nella cache delle immagini native e che entrambi contengano riferimenti a OurDependency.dll. Se MyAssembly.exe viene disinstallato, OurDependency.dll non verrà disinstallato. Quest'ultimo verrà rimosso soltanto dopo la disinstallazione di YourAssembly.exe.

Se si sta generando un'immagine nativa per un assembly nella Global Assembly Cache, è necessario specificare il relativo nome visualizzato. Per informazioni, vedere System.Reflection.Assembly.FullName.

Le immagini native generate da Ngen.exe possono essere condivise tra più domini applicazione. È pertanto possibile utilizzare Ngen.exe in scenari di applicazioni che richiedono la condivisione di assembly tra più domini applicazione. Per specificare l'indipendenza del dominio, effettuare le seguenti operazioni:

• Applicare l'attributo LoaderOptimizationAttribute all'applicazione.

• Impostare la proprietà System.AppDomainSetup.LoaderOptimization quando si creano le informazioni di installazione per un nuovo dominio applicazione.

Durante il caricamento dello stesso assembly in più domini applicazione si consiglia di utilizzare sempre un codice indipendente dal dominio. Se un'immagine nativa viene caricata in un dominio applicazione non condiviso dopo essere stata caricata in un dominio condiviso, tale immagine non potrà essere utilizzata.

Nota

Il codice indipendente dal dominio non può essere scaricato e le prestazioni potranno quindi risultare leggermente inferiori, in particolare durante l'accesso ai membri statici.

Generazione delle immagini per scenari differenti

Una volta generata un'immagine nativa di un assembly, il runtime tenterà automaticamente di individuarla e utilizzarla ogni volta che viene eseguito l'assembly. Possono essere generate più immagini, a seconda degli scenari di utilizzo.

Se ad esempio si esegue un assembly in uno scenario di debug o di profiling, il runtime cercherà un'immagine nativa generata con le opzioni /Debug o /Profile. Se non è possibile individuare un'immagine nativa corrispondente, verrà ripristinata la compilazione JIT standard. L'unico modo per eseguire il debug delle immagini native consiste nel creare un'immagine nativa con l'opzione /Debug.

Poiché l'azione uninstall supporta anche gli scenari, è possibile disinstallare tutti gli scenari o solo quelli selezionati.

Utilizzo delle immagini native

Le immagini native offrono i seguenti vantaggi: utilizzo migliore della memoria e riduzione del tempo di avvio.

Nota

Le prestazioni delle immagini native dipendono da diversi fattori che possono risultare difficili da analizzare, ad esempio i modelli di accesso a dati e codice, il numero delle chiamate effettuate tra i vari moduli e il numero delle dipendenze già caricate da altre applicazioni. L'unico modo per determinare se l'applicazione può trarre benefici dall'utilizzo delle immagini native consiste nell'eseguire un'attenta valutazione delle prestazioni negli scenari di distribuzione chiave.

Utilizzo migliore della memoria

Le immagini native possono migliorare in modo significativo l'utilizzo della memoria quando il codice è condiviso tra più processi. Poiché le immagini native sono file Windows di tipo PE, una singola copia di un file DLL può essere condivisa tra più processi. Il codice nativo prodotto dal compilatore JIT, invece, viene inserito nella memoria privata e non può essere condiviso.

Anche le applicazioni che vengono eseguite in Servizi terminal possono ottenere vantaggi dall'utilizzo di tabelle codice condivise.

Inoltre, il mancato caricamento del compilatore JIT consente di risparmiare una quantità fissa di memoria per ciascuna istanza dell'applicazione.

Avvio più rapido delle applicazioni

La precompilazione degli assembly con Ngen.exe consente di ridurre il tempo di avvio di alcune applicazioni. In generale, i maggiori vantaggi si ottengono con le applicazioni che condividono assembly di componenti. In questo caso, infatti, una volta avviata la prima applicazione, i componenti condivisi risulteranno già caricati per le applicazioni successive. In caso di avvio a freddo, in cui tutti gli assembly di un'applicazione devono essere caricati dal disco rigido, le immagini native non offrono molti vantaggi poiché il tempo di accesso al disco rigido svolge un ruolo predominante.

L'associazione forte può influire negativamente sul tempo di avvio, poiché tutte le immagini associate in maniera forte all'assembly principale dell'applicazione devono essere caricate simultaneamente.

Nota

Se si dispone di componenti condivisi con nome sicuro, si consiglia di memorizzarli nella Global Assembly Cache. Il caricatore, infatti, esegue un ulteriore controllo di convalida sugli assembly con nome sicuro che non si trovano nella Global Assembly Cache, annullando quindi qualsiasi miglioramento a livello di tempo di avvio che era stato possibile ottenere grazie alle immagini native.

Importanza degli indirizzi di base degli assembly

Poiché sono file Windows di tipo PE, le immagini native sono soggette agli stessi problemi di rilocazione degli altri file eseguibili. L'impatto della rilocazione sulle prestazioni risulta ancora più accentuato in caso di utilizzo dell'associazione forte.

Per impostare l'indirizzo di base di un'immagine nativa, utilizzare l'opzione appropriata del compilatore per impostare l'indirizzo di base dell'assembly, che verrà quindi utilizzato da Ngen.exe come indirizzo di base dell'immagine nativa.

Nota

Le immagini native sono più grandi rispetto agli assembly gestiti da cui sono state create. Gli indirizzi di base devono quindi essere calcolati per consentire queste dimensioni maggiori.

Per visualizzare l'indirizzo di base preferenziale di un'immagine nativa è possibile utilizzare uno strumento quale dumpbin.exe.

Considerazioni sull'utilizzo

Di seguito sono riportate alcune considerazioni di carattere generale e specifiche per le applicazioni che possono aiutare a decidere se l'utilizzo delle immagini native può essere una soluzione vantaggiosa per la propria applicazione.

• Le immagini native vengono caricate più rapidamente rispetto al codice MSIL, poiché eliminano la necessità di eseguire molte attività di avvio, ad esempio la compilazione JIT e la verifica dell'indipendenza dai tipi.

• Le immagini native richiedono un working set iniziale più piccolo, poiché il compilatore JIT non è necessario.

• Le immagini native consentono di condividere il codice tra più processi.

• Le immagini native occupano una quantità di spazio su disco maggiore rispetto agli assembly MSIL e possono richiedere molto tempo per la generazione.

• Per le immagini native sono necessarie alcune attività di gestione.

  • Le immagini devono essere rigenerate quando vengono apportate delle modifiche all'assembly originale o a una delle relative dipendenze.

  • È possibile che uno stesso assembly richieda più immagini native da utilizzare in applicazioni o scenari differenti. Ad esempio, le informazioni di configurazione in due applicazioni potrebbero comportare scelte di associazione diverse per lo stesso assembly dipendente.

  • Le immagini native devono essere generate da un amministratore, ovvero da un account Windows del gruppo Administrators.

Oltre a queste considerazioni generali, per determinare se le immagini native possono offrire vantaggi in termini di prestazioni occorre valutare anche la natura dell'applicazione:

• Se l'applicazione viene eseguita in un ambiente che utilizza molti componenti condivisi, le immagini native consentiranno di condividere tali componenti tra più processi.

• Se l'applicazione utilizza più domini applicazione, le immagini native consentiranno di condividere le tabelle codice tra più domini.

  Nota

  In .NET Framework versioni 1.0 e 1.1, le immagini native non possono essere condivise tra più domini applicazione. Questa limitazione è stata rimossa nella versione 2.0.

• Se l'applicazione verrà eseguita in Terminal Server, le immagini native consentiranno di condividere le tabelle codice.

• La compilazione in immagini native in genere comporta un miglioramento delle prestazioni per le applicazioni di grandi dimensioni, ma non in quelle di piccole dimensioni.

• Per le applicazioni a esecuzione prolungata, la compilazione JIT in fase di esecuzione offre prestazioni leggermente migliori rispetto alle immagini native, anche se tale differenza può comunque essere ridotta mediante l'utilizzo dell'associazione forte.

Associazione forte

L'associazione forte consente di migliorare le prestazioni e di ridurre la dimensione del working set per le immagini native. Lo svantaggio consiste nel fatto che tutte le immagini associate in maniera forte a un assembly devono essere caricate al momento del caricamento dell'assembly, che può causare un aumento significativo del tempo di avvio per un'applicazione di grandi dimensioni.

L'associazione forte è appropriata per le dipendenze che vengono caricate in tutti gli scenari dell'applicazione in cui sono necessarie prestazioni particolarmente elevate. Come accade con qualsiasi altro aspetto relativo all'utilizzo delle immagini native, l'unico modo per determinare se l'associazione forte è in grado di migliorare le prestazioni dell'applicazione consiste in un'attenta valutazione delle prestazioni generali.

Gli attributi DependencyAttribute e DefaultDependencyAttribute consentono di fornire a Ngen.exe alcuni suggerimenti per l'utilizzo dell'associazione forte.

Nota

Questi attributi non sono comandi ma semplici suggerimenti e il loro utilizzo non garantisce che l'associazione forte offra vantaggi all'applicazione. Il significato di questi attributi potrebbe cambiare nelle versioni future.

Specifica di un suggerimento di associazione per una dipendenza

Applicare l'attributo DependencyAttribute a un assembly per indicare la probabilità che una specifica dipendenza verrà caricata. System.Runtime.CompilerServices.LoadHint.Always indica che l'associazione forte è appropriata, Default indica che deve essere utilizzato il valore predefinito per la dipendenza e Sometimes indica che l'associazione forte non è appropriata.

Nell'esempio di codice riportato di seguito vengono illustrati gli attributi per un assembly con due dipendenze. La prima dipendenza (Assembly1) è un candidato appropriato per l'associazione forte, al contrario della seconda (Assembly2).

Imports System.Runtime.CompilerServices
<Assembly:DependencyAttribute("Assembly1", LoadHint.Always)>
<Assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)>

using System.Runtime.CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)]
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)]

using namespace System::Runtime::CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)];
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)];

Il nome dell'assembly non include l'estensione ed è possibile utilizzare i nomi visualizzati.

Specifica di un suggerimento di associazione predefinita per un assembly

I suggerimenti di associazione predefinita sono necessari solo per gli assembly che verranno utilizzati immediatamente e di frequente da una qualsiasi applicazione che possiede una dipendenza da tali assembly. Applicare l'attributo DefaultDependencyAttribute con System.Runtime.CompilerServices.LoadHint.Always a tali assembly per specificare che deve essere utilizzata l'associazione forte.

Nota

Non esiste alcun motivo per applicare DefaultDependencyAttribute agli assembly dll che non rientrano in questa categoria, poiché l'applicazione dell'attributo con un qualsiasi valore diverso da System.Runtime.CompilerServices.LoadHint.Always non ha alcun effetto.

Microsoft utilizza l'attributo DefaultDependencyAttribute per specificare che l'associazione forte è l'impostazione predefinita per un numero molto piccolo di assembly in .NET Framework, ad esempio mscorlib.dll.

Risoluzione dei problemi

Per assicurarsi che le immagini native vengano utilizzate dall'applicazione, è possibile utilizzare il Visualizzatore log associazione assembly (Fuslogvw.exe). Selezionare Native Images nella casella Log Categories della finestra del visualizzatore log associazione. Questo strumento fornisce informazioni sul motivo del rifiuto di un'immagine nativa.

È possibile utilizzare l'assistente al debug gestito JitCompilationStart per determinare quando il compilatore JIT inizia a compilare una funzione.

Rinvio dell'elaborazione

La generazione delle immagini native per un'applicazione di grandi dimensioni può richiedere molto tempo. In modo analogo, le modifiche a un componente condiviso o alle impostazioni del computer potrebbero richiedere l'aggiornamento di numerose immagini native. Per le azioni install e update è disponibile un'opzione /queue che consente di rinviarne l'esecuzione dell'operazione utilizzando il servizio immagini native. Inoltre, per Ngen.exe sono disponibili le azioni queue e executeQueuedItems che forniscono un certo grado di controllo sul servizio. Per ulteriori informazioni, vedere Servizio immagini native.

Immagini native e compilazione JIT

Se Ngen.exe individua in un assembly metodi che non possono essere generati, li esclude dall'immagine nativa. Quando il runtime eseguirà questo assembly, utilizzerà la compilazione JIT per i metodi che non sono stati inclusi nell'immagine nativa.

Inoltre, le immagini native non vengono utilizzate se l'assembly è stato aggiornato o se l'immagine è stata invalidata per qualche motivo.

Immagini non valide

Quando si utilizza Ngen.exe per creare un'immagine nativa di un assembly, l'output dipenderà dalle opzioni della riga di comando specificate e da alcune impostazioni del computer, tra cui:

• Versione di .NET Framework.

• Versione del sistema operativo, se si è passati dalla famiglia Windows 9x alla famiglia Windows NT.

• Identità esatta dell'assembly (l'identità cambia ad ogni ricompilazione).

• Identità esatta di tutti gli assembly a cui l'assembly fa riferimento (l'identità cambia ad ogni ricompilazione).

• Fattori di protezione.

Quando genera un'immagine nativa, Ngen.exe registra queste informazioni. Quando si esegue un assembly, il runtime cerca l'immagine nativa generata con le opzioni e le impostazioni che corrispondono all'ambiente corrente del computer. Se non viene individuata un'immagine nativa corrispondente, verrà ripristinata la compilazione JIT di un assembly. Le modifiche alle impostazioni e all'ambiente di un computer che rendono non valide le immagini native sono le seguenti:

• Versione di .NET Framework.

  Se viene eseguito un aggiornamento di .NET Framework, tutte le immagini native create utilizzando Ngen.exe non saranno più valide. Per questo motivo, tutti gli aggiornamenti di .NET Framework eseguono il comando Ngen Update per garantire che tutte le immagini native vengano rigenerate. .NET Framework crea automaticamente nuove immagini native per le librerie di .NET Framework installate.

• Versione del sistema operativo, se si è passati dalla famiglia Windows 9x alla famiglia Windows NT.

  Se ad esempio la versione del sistema operativo in esecuzione su un computer passa da Windows 98 a Windows XP, tutte le immagini native memorizzate nella cache delle immagini native non saranno più valide. Tuttavia, se si passa da Windows 2000 a Windows XP, le immagini continueranno a essere valide.

• Identità esatta dell'assembly.

  Se si ricompila un assembly, l'immagine nativa corrispondente diventerà non valida.

• Identità esatta di tutti gli assembly a cui fa riferimento l'assembly.

  Se si aggiorna un assembly gestito, tutte le immagini native che dipendono direttamente o indirettamente dall'assembly in questione diventano non valide e devono essere rigenerate. Sono inclusi in tal senso i riferimenti ordinari e le dipendenze con associazione forte. Ogni volta che viene applicato un aggiornamento software, il programma di installazione esegue un comando Ngen Update per garantire che tutte le immagini native dipendenti vengano rigenerate.

• Fattori di protezione.

  La modifica dei criteri di protezione del computer per limitare le autorizzazioni concesse in precedenza a un assembly può rendere non valida un'immagine nativa compilata in precedenza per l'assembly in questione.

  Per informazioni dettagliate sulla gestione della protezione dall'accesso di codice da parte di Common Language Runtime e su come utilizzare le autorizzazioni, vedere Protezione dall'accesso di codice.

Esempi

Il comando riportato di seguito consente di generare un'immagine nativa per ClientApp.exe, situato nella directory corrente, e di installarla nella cache delle immagini native. Se esiste un file di configurazione per l'assembly, tale file verrà utilizzato da Ngen.exe. Verranno inoltre generate immagini native per gli eventuali file DLL a cui fa riferimento ClientApp.exe.

ngen install ClientApp.exe

Un'immagine installata con Ngen.exe viene anche detta radice. Una radice può essere un'applicazione o un componente condiviso.

Il comando riportato di seguito consente di generare un'immagine nativa per MyAssembly.exe con il percorso specificato.

ngen install c:\myfiles\MyAssembly.exe

Per l'individuazione degli assembly e delle relative dipendenze, Ngen.exe utilizza la stessa logica di ricerca utilizzata da Common Language Runtime. Per impostazione predefinita, la directory contenente ClientApp.exe viene utilizzata come directory della base dell'applicazione e tutte le ricerche degli assembly iniziano in questa directory. Per cambiare questo comportamento è possibile utilizzare l'opzione /AppBase.

Nota

Si tratta di una variazione rispetto al comportamento di Ngen.exe in .NET Framework versioni 1.0 e 1.1, in cui la base dell'applicazione viene impostata sulla directory corrente.

Un assembly può avere una dipendenza senza un riferimento, ad esempio se carica un file DLL utilizzando il metodo System.Reflection.Assembly.Load. È possibile creare un'immagine nativa per tale file utilizzando le informazioni di configurazione dell'assembly dell'applicazione, con l'opzione /ExeConfig. Il comando riportato di seguito consente di generare un'immagine nativa per MyLib.dll, utilizzando le informazioni di configurazione di MyApp.exe.

ngen install c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

Gli assembly installati con questa modalità non vengono rimossi se l'applicazione viene disinstallata.

Per disinstallare una dipendenza, è necessario utilizzare le stesse opzioni della riga di comando utilizzate per l'installazione. Il comando riportato di seguito consente di disinstallare il file MyLib.dll dell'esempio precedente.

ngen uninstall c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

Per creare un'immagine nativa per un assembly nella Global Assembly Cache, utilizzare il nome visualizzato dell'assembly, Esempio:

ngen install "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"

Ngen.exe genera un gruppo di immagini separato per ciascuno scenario installato. I comandi riportati di seguito, ad esempio, consentono di installare un gruppo completo di immagini native per le normali operazioni, un altro gruppo completo per il debug e un terzo gruppo per il profiling:

ngen install MyApp.exe
ngen install MyApp.exe /debug
ngen install MyApp.exe /profile

Visualizzazione della cache delle immagini native

Una volta installate nella cache, le immagini native possono essere visualizzate mediante Ngen.exe. Il comando riportato di seguito consente di visualizzare tutte le immagini native contenute nella cache delle immagini native.

ngen display

L'azione display elenca prima tutti gli assembly radice e quindi tutte le immagini native presenti sul computer.

Utilizzare il nome semplice di un assembly per visualizzare soltanto le informazioni relative a tale assembly. Il comando riportato di seguito consente di visualizzare tutte le immagini native contenute nella cache delle immagini native corrispondenti al nome parziale MyAssembly, tutte le relative dipendenze e tutte le radici che hanno una dipendenza da MyAssembly:

ngen display MyAssembly

La possibilità di conoscere quali radici dipendono da un assembly di un componente condiviso risulta utile per la valutazione dell'impatto di un'azione update dopo l'aggiornamento del componente condiviso.

Se si specifica l'estensione di un assembly, è necessario specificare il percorso o eseguire Ngen.exe dalla directory contenente l'assembly:

ngen display c:\myApps\MyAssembly.exe

Il comando riportato di seguito consente di visualizzare tutte le immagini native contenute nella cache delle immagini native con nome MyAssembly e versione 1.0.0.0.

ngen display "myAssembly, version=1.0.0.0"

Aggiornamento delle immagini

Le immagini in genere vengono aggiornate dopo l'aggiornamento di un componente condiviso. Per aggiornare tutte le immagini native modificate, o le cui dipendenze sono state modificate, utilizzare l'azione update senza alcun argomento.

ngen update

L'aggiornamento di tutte le immagini può richiedere molto tempo. Per questo motivo, è possibile utilizzare l'opzione /queue per accodare gli aggiornamenti in modo che vengano eseguiti dal servizio immagini native. Per ulteriori informazioni sull'opzione /queue e sulle priorità di installazione, vedere Servizio immagini native.

ngen update /queue

Disinstallazione delle immagini

Poiché Ngen.exe mantiene un elenco di dipendenze, i componenti condivisi verranno rimossi solo quando saranno stati rimossi tutti gli assembly che dipendono da tali componenti. Inoltre, un componente condiviso installato come radice non verrà mai rimosso.

Il comando riportato di seguito consente di disinstallare tutti gli scenari per la radice ClientApp.exe:

ngen uninstall ClientApp

L'azione uninstall può essere utilizzata per rimuovere scenari specifici. Il comando riportato di seguito consente di disinstallare tutti gli scenari di debug per ClientApp.exe:

ngen uninstall ClientApp /debug

Nota

La disinstallazione degli scenari /debug non comporta la disinstallazione di uno scenario che include sia /profile che /debug.

Il comando riportato di seguito consente di disinstallare tutti gli scenari per una versione specifica di ClientApp.exe:

ngen uninstall "ClientApp, Version=1.0.0.0"

I comandi riportati di seguito consentono di disinstallare tutti gli scenari per "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL", o semplicemente lo scenario di debug per tale assembly:

ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"
ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral, 
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL" /debug

Come con l'azione install, l'eventuale presenza dell'estensione richiede l'esecuzione di Ngen.exe dalla directory contenente l'assembly o la specifica di un percorso completo.

Per esempi relativi al servizio immagini native, vedere Servizio immagini native.

Vedere anche

Riferimenti

Strumenti di .NET Framework
Prompt dei comandi di SDK

Concetti

Servizio immagini native
Compilazione di MSIL in codice nativo
Come il runtime individua gli assembly