Ngen.exe (generatore di immagini native)

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. Il runtime può utilizzare le immagini native della cache anziché il compilatore Just-In-Time (JIT) per compilare l'assembly originale.

Modifiche di Ngen.exe in .NET Framework versione 4:

• Ngen.exe compila assembly con attendibilità totale e i criteri di sicurezza dall'accesso di codice (CAS, Code Access Security) non vengono più valutati.

• Immagini native generate con Ngen.exe non possono più essere caricate in applicazioni in modalità di esecuzione parzialmente attendibile.

Modifiche di Ngen.exe 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 legacy del generatore di immagini native (Ngen.exe).

Questo strumento viene installato automaticamente con Visual Studio e con Windows SDK. Per eseguire lo strumento, si consiglia di utilizzare il prompt dei comandi di Visual Studio o il prompt dei comandi di Windows SDK (shell di CMD). Queste utilità consentono di eseguire facilmente lo strumento, senza dover passare alla cartella di installazione. Per ulteriori informazioni, vedere Prompt dei comandi di Visual Studio e Windows SDK.

• Se si dispone di Visual Studio installato sul computer: nella barra delle applicazioni, fare clic su Start, fare clic su All Programs, fare clic su Visual Studio, fare clic su Visual Studio Tools e quindi su Visual Studio Command Prompt.

  In alternativa

  Se si dispone di Windows SDK installato sul computer: nella barra delle applicazioni, fare clic su Start, fare clic su All Programs, fare clic sulla cartella di Windows SDK e quindi su Command Prompt (o CMD Shell).

• Al prompt dei comandi digitare quanto segue:

ngen action [options]
ngen /? | /help

Azioni

Nella tabella riportata di seguito viene illustrata la sintassi di ciascuna action. Per le descrizioni delle singole parti di action, vedere le tabelle Argomenti, Livelli di priorità, Scenari e Configurazione. Nella tabella Opzioni vengono descritte le options e le opzioni della Guida.

Azione	Oggetto di 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. Vedere la tabella dei livelli di priorità.
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. Nota In .NET Framework versione 4, l'azione uninstall non è più supportata.
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] In alternativa eqi [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	Oggetto di descrizione
assemblyName	Nome visualizzato completo dell'assembly, Ad esempio "myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5". Nota È possibile fornire un nome parziale di assembly, ad esempio myAssembly, per le azioni display e uninstall. È 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.

Livelli di priorità

Scenari

Configurazione

Opzioni

Opzione	Oggetto di 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.

Attenzione
Non eseguire Ngen.exe su assembly che non sono completamente attendibili.A partire da .NET Framework versione 4, Ngen.exe compila assembly con attendibilità totale e i criteri di sicurezza dall'accesso di codice (CAS, Code Access Security) non vengono più valutati.

A partire da .NET Framework 4, le immagini native generate con Ngen.exe non possono più essere caricate in applicazioni in modalità di esecuzione parzialmente attendibile. Viene invece richiamato il compilatore JIT.

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 Assembly.Load.

Importante
Non utilizzare il metodo 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. Vedere 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à 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

Prima di .NET Framework 3.5 Service Pack 1 conviene inserire i componenti condivisi con nome sicuro nella Global Assembly Cache, perché il caricatore 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.Le ottimizzazioni introdotte in .NET Framework 3.5 SP1 hanno rimosso la convalida aggiuntiva.

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 o successiva.

• 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 suggerimentie 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 DependencyAttribute a un assembly per indicare la probabilità che una dipendenza specificata venga caricata. LoadHint.Always indicates that hard binding is appropriate, 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 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 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 Fuslogvw.exe (Visualizzatore log associazioni assembly). 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 MDA 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 sicurezza.

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 sicurezza.

  La modifica dei criteri di sicurezza 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 sul modo con cui Common Language Runtime gestisce la sicurezza di accesso al codice e sull'utilizzo delle autorizzazioni, vedere Sicurezza 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 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, Di seguito è riportato un 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 immagini native nella cache, è possibile visualizzarle utilizzando Ngen.exe. Il comando riportato di seguito consente di visualizzare tutte le immagini native presenti 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

Prompt dei comandi di Visual Studio e Windows SDK

Concetti

Servizio immagini native

Processo di esecuzione gestita

Come il runtime individua gli assembly

Altre risorse

Strumenti di .NET Framework

Cronologia delle modifiche