Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il generatore di immagini native (Ngen.exe) è uno strumento che migliora le prestazioni delle applicazioni gestite. Ngen.exe crea immagini native, ovvero file contenenti codice computer specifico del processore compilato e li installa nella cache delle immagini nativa nel computer locale. Il runtime può usare immagini native dalla cache invece di usare il compilatore JIT (Just-In-Time) per compilare l'assembly originale.
Annotazioni
Ngen.exe compila immagini native per gli assembly destinati solo a .NET Framework. Il generatore di immagini native equivalente per .NET Core è CrossGen.
Modifiche apportate a Ngen.exe in .NET Framework 4:
Ngen.exe ora compila gli assembly con attendibilità totale e i criteri di sicurezza dall'accesso al codice non vengono più valutati.
Le immagini native generate con Ngen.exe non possono più essere caricate in applicazioni in esecuzione con attendibilità parziale.
Modifiche apportate a Ngen.exe in .NET Framework versione 2.0:
L'installazione di un assembly installa anche le relative dipendenze, semplificando la sintassi di Ngen.exe.
Le immagini native possono ora essere condivise tra domini applicazione.
Nuova azione,
update, ricrea le immagini invalidate.Le azioni possono essere posticipate per l'esecuzione da parte di un servizio che usa il tempo di inattività nel computer per generare e installare immagini.
Alcune cause di invalidazione dell'immagine sono state eliminate.
In Windows 8, vedi Attività immagine nativa.
Per altre informazioni sull'uso di Ngen.exe e sul servizio immagini nativo, vedere Servizio immagini native.
Annotazioni
Ngen.exe sintassi per le versioni 1.0 e 1.1 di .NET Framework sono disponibili nella sintassi legacy del generatore di immagini native (Ngen.exe).
Viene installato automaticamente con Visual Studio. Per eseguire lo strumento, usare il prompt dei comandi per gli sviluppatori di Visual Studio o Visual Studio Developer PowerShell.
Al prompt dei comandi digitare quanto segue:
Sintassi
ngen action [options]
ngen /? | /help
Azioni
Nella tabella seguente viene illustrata la sintassi di ogni actionoggetto . Per le descrizioni delle singole parti di un actionoggetto , vedere le tabelle Arguments, Priority Levels, Scenarios e Config . Nella tabella Opzioni vengono descritte le opzioni della options Guida e .
| Action | Description |
|---|---|
install[assemblyName | assemblyPath] [] [configscenarios] [/queue[:{1||23}]] |
Generare immagini native per un assembly e le relative dipendenze e installare le immagini nella cache delle immagini native. Se /queue viene specificato, l'azione viene accodata per il servizio immagini nativo. La priorità predefinita è 3. Vedere la tabella Livelli di priorità . |
uninstall[] [assemblyNamescenarios | assemblyPath] [] []config |
Eliminare le immagini native di un assembly e le relative dipendenze dalla cache delle immagini native. Per disinstallare una singola immagine e le relative dipendenze, usare gli stessi argomenti della riga di comando usati per installare l'immagine. Nota: A partire da .NET Framework 4, l'azione uninstall * non è più supportata. |
update [/queue] |
Aggiornare le immagini native che non sono più valide. Se /queue viene specificato, gli aggiornamenti vengono accodati per il servizio immagini nativo. Gli aggiornamenti vengono sempre pianificati con priorità 3, quindi vengono eseguiti quando il computer è inattiva. |
display [assemblyName | assemblyPath] |
Visualizzare lo stato delle immagini native per un assembly e le relative dipendenze. Se non viene specificato alcun argomento, viene visualizzato tutto ciò che si trova nella cache di immagini native. |
executeQueuedItems [1|2|3]oppure eqi [1|2|3] |
Eseguire processi di compilazione in coda. Se viene specificata una priorità, vengono eseguiti i processi di compilazione con priorità maggiore o uguale. Se non viene specificata alcuna priorità, vengono eseguiti tutti i processi di compilazione in coda. |
queue{pause | | continuestatus} |
Sospendere il servizio immagini nativo, consentire al servizio sospeso di continuare o eseguire una query sullo stato del servizio. |
Arguments
| Argomentazione | Description |
|---|---|
assemblyName |
Nome visualizzato completo dell'assembly. Ad esempio: "myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5".
Nota: È possibile specificare un nome di assembly parziale, ad esempio myAssembly, per le display azioni e uninstall . È possibile specificare un solo assembly per Ngen.exe riga di comando. |
assemblyPath |
Percorso esplicito dell'assembly. È possibile specificare un percorso completo o relativo. Se si specifica un nome di file senza un percorso, l'assembly deve trovarsi nella directory corrente. È possibile specificare un solo assembly per Ngen.exe riga di comando. |
Livelli di priorità
| Priority | Description |
|---|---|
1 |
Le immagini native vengono generate e installate immediatamente, senza attendere il tempo di inattività. |
2 |
Le immagini native vengono generate e installate senza attendere il tempo di inattività, ma dopo che tutte le azioni con priorità 1 (e le relative dipendenze) sono state completate. |
3 |
Le immagini native vengono installate quando il servizio immagini native rileva che il computer è inattiva. Vedere Servizio immagini native. |
Scenarios
| Scenario | Description |
|---|---|
/Debug |
Generare immagini native che possono essere usate in un debugger. |
/Profile |
Generare immagini native che possono essere usate in un profiler. |
/NoDependencies |
Generare il numero minimo di immagini native richieste dalle opzioni di scenario specificate. |
Config
| Configurazione | Description |
|---|---|
/ExeConfig:
exePath
|
Usare la configurazione dell'assembly eseguibile specificato. Ngen.exe deve prendere le stesse decisioni del caricatore quando si esegue l'associazione alle dipendenze. Quando un componente condiviso viene caricato in fase di esecuzione, usando il Load metodo , il file di configurazione dell'applicazione determina le dipendenze caricate per il componente condiviso, ad esempio la versione di una dipendenza caricata. L'opzione /ExeConfig fornisce Ngen.exe indicazioni su quali dipendenze verranno caricate in fase di esecuzione. |
/AppBase:
directoryPath
|
Quando si individuano le dipendenze, usare la directory specificata come base dell'applicazione. |
Options
| Opzione | Description |
|---|---|
/nologo |
Eliminare la visualizzazione del banner di avvio Di Microsoft. |
/silent |
Eliminare la visualizzazione dei messaggi di operazione riuscita. |
/verbose |
Visualizzare informazioni dettagliate per il debug. |
/help, /? |
Visualizzare la sintassi e le opzioni dei comandi per la versione corrente. |
Osservazioni:
Per eseguire Ngen.exe, è necessario disporre di privilegi amministrativi.
Attenzione
Non eseguire Ngen.exe sugli assembly non completamente attendibili. A partire da .NET Framework 4, Ngen.exe compila gli assembly con attendibilità totale e i criteri di sicurezza dall'accesso al codice non vengono più valutati.
A partire da .NET Framework 4, le immagini native generate con Ngen.exe non possono più essere caricate nelle applicazioni in esecuzione con attendibilità parziale. Viene invece richiamato il compilatore JIT (Just-In-Time).
Ngen.exe genera immagini native per l'assembly specificato dall'argomento per l'azione assemblynameinstall e tutte le relative dipendenze. Le dipendenze vengono determinate dai riferimenti nel manifesto dell'assembly. L'unico scenario in cui è necessario installare una dipendenza separatamente è quando l'applicazione la carica usando reflection, ad esempio chiamando il Assembly.Load metodo .
Importante
Non usare il Assembly.LoadFrom metodo con immagini native. Un'immagine caricata con questo metodo non può essere usata da altri assembly nel contesto di esecuzione.
Ngen.exe gestisce un conteggio delle dipendenze. Si supponga MyAssembly.exe , ad esempio, che e YourAssembly.exe siano entrambi installati nella cache di immagini native e che abbiano entrambi riferimenti a OurDependency.dll. Se MyAssembly.exe viene disinstallato, OurDependency.dll non viene disinstallato. Viene rimosso solo quando YourAssembly.exe viene disinstallato.
Se si genera un'immagine nativa per un assembly nella Global Assembly Cache, specificarne il nome visualizzato. Vedi Assembly.FullName.
Le immagini native generate Ngen.exe possono essere condivise tra domini applicazione. Ciò significa che è possibile usare Ngen.exe negli scenari dell'applicazione che richiedono la condivisione di assembly tra domini applicazione. Per specificare la neutralità del dominio:
Applicare l'attributo LoaderOptimizationAttribute all'applicazione.
Impostare la AppDomainSetup.LoaderOptimization proprietà quando si creano informazioni di installazione per un nuovo dominio applicazione.
Usare sempre codice indipendente dal dominio durante il caricamento dello stesso assembly in più domini applicazione. Se un'immagine nativa viene caricata in un dominio applicazione non condiviso dopo essere stata caricata in un dominio condiviso, non può essere usata.
Annotazioni
Il codice indipendente dal dominio non può essere scaricato e le prestazioni potrebbero risultare leggermente più lente, in particolare quando si accede a membri statici.
In questa sezione Osservazioni:
Generazione di immagini per scenari diversi
Dopo aver generato un'immagine nativa per un assembly, il runtime tenta automaticamente di individuare e usare questa immagine nativa ogni volta che esegue l'assembly. È possibile generare più immagini, a seconda degli scenari di utilizzo.
Ad esempio, se si esegue un assembly in uno scenario di debug o profilatura, il runtime cerca un'immagine nativa generata con le /Debug opzioni o /Profile . Se non è in grado di trovare un'immagine nativa corrispondente, il runtime ripristina la compilazione JIT standard. L'unico modo per eseguire il debug di immagini native consiste nel creare un'immagine nativa con l'opzione /Debug .
L'azione uninstall riconosce anche gli scenari, in modo da poter disinstallare tutti gli scenari o solo gli scenari selezionati.
Determinazione di quando usare immagini native
Le immagini native possono offrire miglioramenti delle prestazioni in due aree: uso migliorato della memoria e riduzione del tempo di avvio.
Annotazioni
Le prestazioni delle immagini native dipendono da diversi fattori che rendono difficile l'analisi, ad esempio modelli di codice e di accesso ai dati, il numero di chiamate effettuate attraverso i limiti del modulo e il numero di dipendenze già caricate da altre applicazioni. L'unico modo per determinare se le immagini native traggono vantaggio dall'applicazione consiste nell'eseguire un'attenta misurazione delle prestazioni negli scenari di distribuzione chiave.
Miglioramento dell'uso della memoria
Le immagini native possono migliorare significativamente l'uso della memoria quando il codice viene condiviso tra processi. Le immagini native sono file Windows PE, quindi una singola copia di un file .dll può essere condivisa da più processi; Al contrario, il codice nativo prodotto dal compilatore JIT viene archiviato in memoria privata e non può essere condiviso.
Le applicazioni eseguite nei servizi terminal possono anche trarre vantaggio dalle tabelle codici condivise.
Inoltre, il mancato caricamento del compilatore JIT consente di risparmiare una quantità fissa di memoria per ogni istanza dell'applicazione.
Avvio più rapido dell'applicazione
La precompilazione degli assembly con Ngen.exe può migliorare il tempo di avvio per alcune applicazioni. In generale, è possibile ottenere miglioramenti quando le applicazioni condividono assembly di componenti perché dopo l'avvio della prima applicazione i componenti condivisi sono già stati caricati per le applicazioni successive. L'avvio a freddo, in cui tutti gli assembly in un'applicazione devono essere caricati dal disco rigido, non traggono vantaggio tanto dalle immagini native perché il tempo di accesso al disco rigido prevale.
Il binding rigido può influire sul tempo di avvio, perché tutte le immagini hard bound all'assembly principale dell'applicazione devono essere caricate contemporaneamente.
Annotazioni
Prima di .NET Framework 3.5 Service Pack 1, è necessario inserire componenti condivisi con nome sicuro nella Global Assembly Cache, perché il caricatore esegue una convalida aggiuntiva su assembly con nome sicuro che non si trovano nella Global Assembly Cache, eliminando in modo efficace eventuali miglioramenti nel tempo di avvio ottenuto usando immagini native. Le ottimizzazioni introdotte in .NET Framework 3.5 SP1 hanno rimosso la convalida aggiuntiva.
Riepilogo delle considerazioni sull'utilizzo
Le considerazioni generali e le considerazioni sull'applicazione seguenti possono essere utili per decidere se intraprendere lo sforzo di valutare le immagini native per l'applicazione:
Le immagini native caricano più velocemente di CIL perché eliminano la necessità di molte attività di avvio, ad esempio la compilazione JIT e la verifica della sicurezza dei tipi.
Le immagini native richiedono un working set iniziale più piccolo perché non è necessario il compilatore JIT.
Le immagini native consentono la condivisione del codice tra processi.
Le immagini native richiedono più spazio su disco rigido rispetto agli assembly CIL e possono richiedere molto tempo per la generazione.
Le immagini native devono essere mantenute.
Le immagini devono essere rigenerate quando viene gestito l'assembly originale o una delle relative dipendenze.
Un singolo assembly può richiedere più immagini native per l'uso in applicazioni diverse o in scenari diversi. Ad esempio, le informazioni di configurazione in due applicazioni possono comportare decisioni di associazione diverse per lo stesso assembly dipendente.
Le immagini native devono essere generate da un amministratore; ovvero da un account di Windows nel gruppo Administrators.
Oltre a queste considerazioni generali, la natura dell'applicazione deve essere considerata quando si determina se le immagini native possono offrire un vantaggio in termini di prestazioni:
Se l'applicazione viene eseguita in un ambiente che usa molti componenti condivisi, le immagini native consentono la condivisione dei componenti da parte di più processi.
Se l'applicazione usa più domini applicazione, le immagini native consentono la condivisione delle tabelle codici tra domini.
Annotazioni
In .NET Framework versioni 1.0 e 1.1 le immagini native non possono essere condivise tra domini applicazione. Questo non è il caso nella versione 2.0 o successiva.
Se l'applicazione verrà eseguita in Terminal Server, le immagini native consentono la condivisione delle tabelle codici.
Le applicazioni di grandi dimensioni in genere traggono vantaggio dalla compilazione alle immagini native. Le applicazioni di piccole dimensioni in genere non traggono vantaggio.
Per le applicazioni a esecuzione prolungata, la compilazione JIT di runtime offre prestazioni leggermente migliori rispetto alle immagini native. Il binding rigido può attenuare questa differenza di prestazioni in qualche modo.
Importanza degli indirizzi di base dell'assembly
Poiché le immagini native sono file Windows PE, sono soggette agli stessi problemi di ribasing di altri file eseguibili. Il costo delle prestazioni di rilocazione è ancora più pronunciato se viene utilizzato il binding rigido.
Per impostare l'indirizzo di base per un'immagine nativa, usare l'opzione appropriata del compilatore per impostare l'indirizzo di base per l'assembly. Ngen.exe usa questo indirizzo di base per l'immagine nativa.
Annotazioni
Le immagini native sono più grandi degli assembly gestiti da cui sono stati creati. Gli indirizzi di base devono essere calcolati per consentire queste dimensioni maggiori.
È possibile usare uno strumento come dumpbin.exe per visualizzare l'indirizzo di base preferito di un'immagine nativa.
Binding rigido
Il binding rigido aumenta la velocità effettiva e riduce le dimensioni del set di lavoro per le immagini native. Lo svantaggio del binding rigido è che tutte le immagini hard bound a un assembly devono essere caricate quando viene caricato l'assembly. Questo può aumentare significativamente il tempo di avvio per un'applicazione di grandi dimensioni.
Il binding rigido è appropriato per le dipendenze caricate in tutti gli scenari critici per le prestazioni dell'applicazione. Come per qualsiasi aspetto dell'uso di immagini native, le misurazioni accurate delle prestazioni sono l'unico modo per determinare se il binding rigido migliora le prestazioni dell'applicazione.
Gli DependencyAttribute attributi e DefaultDependencyAttribute consentono di fornire hint di binding rigido per Ngen.exe.
Annotazioni
Questi attributi sono hint per Ngen.exe, non per i comandi. L'uso non garantisce l'associazione rigida. Il significato di questi attributi può cambiare nelle versioni future.
Specifica di un hint di associazione per una dipendenza
DependencyAttribute Applicare a un assembly per indicare la probabilità che venga caricata una dipendenza specificata. LoadHint.Always indica che il binding rigido è appropriato, Default indica che l'impostazione predefinita per la dipendenza deve essere usata e Sometimes indica che il binding rigido non è appropriato.
Il codice seguente illustra gli attributi per un assembly con due dipendenze. La prima dipendenza (Assembly1) è un candidato appropriato per il binding rigido e la seconda (Assembly2) non è .
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 del nome file. I nomi visualizzati possono essere usati.
Specifica di un hint di associazione predefinito per un assembly
Gli hint di associazione predefiniti sono necessari solo per gli assembly che verranno usati immediatamente e frequentemente da qualsiasi applicazione con una dipendenza da essi. Applicare con DefaultDependencyAttributeLoadHint.Always a tali assembly per specificare che deve essere usato il binding rigido.
Annotazioni
Non esiste alcun motivo per applicare DefaultDependencyAttribute agli assembly .dll che non rientrano in questa categoria, perché l'applicazione dell'attributo con qualsiasi valore diverso LoadHint.Always da ha lo stesso effetto di non applicare affatto l'attributo.
Microsoft usa per DefaultDependencyAttribute specificare che il binding rigido è l'impostazione predefinita per un numero molto ridotto di assembly in .NET Framework, ad esempio mscorlib.dll.
Elaborazione posticipata
La generazione di immagini native per un'applicazione molto grande può richiedere molto tempo. Analogamente, le modifiche apportate a un componente condiviso o alle modifiche apportate alle impostazioni del computer potrebbero richiedere l'aggiornamento di molte immagini native. Le install azioni e update hanno un'opzione /queue che accoda l'operazione per l'esecuzione posticipata dal servizio immagini nativo. Inoltre, Ngen.exe dispone queue di azioni e executeQueuedItems che forniscono un certo controllo sul servizio. Per altre informazioni, vedere Servizio immagini native.
Immagini native e compilazione JIT
Se Ngen.exe rileva metodi in un assembly che non può generare, li esclude dall'immagine nativa. Quando il runtime esegue questo assembly, viene ripristinata la compilazione JIT per i metodi non inclusi nell'immagine nativa.
Inoltre, le immagini native non vengono usate se l'assembly è stato aggiornato o se l'immagine è stata invalidata per qualsiasi motivo.
Immagini non valide
Quando si usa Ngen.exe per creare un'immagine nativa di un assembly, l'output dipende dalle opzioni della riga di comando specificate e determinate impostazioni nel computer. Tali impostazioni includono quanto segue:
Versione di .NET Framework.
L'identità esatta dell'assembly (la ricompilazione modifica l'identità).
Identità esatta di tutti gli assembly a cui fa riferimento l'assembly (la ricompilazione modifica l'identità).
Fattori di sicurezza.
Ngen.exe registra queste informazioni quando genera un'immagine nativa. Quando si esegue un assembly, il runtime cerca l'immagine nativa generata con opzioni e impostazioni che corrispondono all'ambiente corrente del computer. Il runtime ripristina la compilazione JIT di un assembly se non riesce a trovare un'immagine nativa corrispondente. Le modifiche seguenti alle impostazioni e all'ambiente di un computer causano l'invalidità delle immagini native:
Versione di .NET Framework.
Se si applica un aggiornamento a .NET Framework, tutte le immagini native create con Ngen.exe diventano non valide. Per questo motivo, tutti gli aggiornamenti di .NET Framework eseguono il
Ngen Updatecomando per assicurarsi che tutte le immagini native vengano rigenerate. .NET Framework crea automaticamente nuove immagini native per le librerie .NET Framework installate.Identità esatta dell'assembly.
Se si ricompila un assembly, l'immagine nativa corrispondente dell'assembly diventa 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 da tale assembly diventano non valide e devono essere rigenerate. Sono inclusi sia i riferimenti ordinari che le dipendenze hard-bound. Ogni volta che viene applicato un aggiornamento software, il programma di installazione deve eseguire un
Ngen Updatecomando per assicurarsi 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ò causare l'invalidità di un'immagine nativa compilata in precedenza per tale assembly.
Per informazioni dettagliate su come Common Language Runtime amministra la sicurezza dell'accesso al codice e su come usare le autorizzazioni, vedere Sicurezza dall'accesso al codice.
Risoluzione dei problemi
Gli argomenti di risoluzione dei problemi seguenti consentono di vedere quali immagini native vengono usate e quali non possono essere usate dall'applicazione, per determinare quando il compilatore JIT inizia a compilare un metodo e illustra come rifiutare esplicitamente la compilazione di immagini native dei metodi specificati.
Visualizzatore log associazione assembly
Per verificare che le immagini native vengano usate dall'applicazione, è possibile usare ilFuslogvw.exe (Visualizzatore log associazione assembly).To confirm that native images are used by your application, you can use the Fuslogvw.exe (Assembly Binding Log Viewer). Selezionare Immagini native nella casella Categorie di log nella finestra del visualizzatore log di associazione. Fuslogvw.exe fornisce informazioni sul motivo per cui un'immagine nativa è stata rifiutata.
Assistente al debug gestito JITCompilationStart
È possibile usare jitCompilationStart Managed Debugging Assistant (MDA) per determinare quando il compilatore JIT inizia a compilare una funzione.
Rifiuto esplicito della generazione di immagini native
In alcuni casi, NGen.exe potrebbe avere difficoltà a generare un'immagine nativa per un metodo specifico oppure si preferisce che il metodo sia compilato JIT anziché compilato in un'immagine nativa. In questo caso, è possibile usare l'attributo System.Runtime.BypassNGenAttribute per impedire NGen.exe di generare un'immagine nativa per un metodo specifico. L'attributo deve essere applicato singolarmente a ogni metodo il cui codice non si vuole includere nell'immagine nativa. NGen.exe riconosce l'attributo e non genera codice nell'immagine nativa per il metodo corrispondente.
Si noti, tuttavia, che BypassNGenAttribute non è definito come tipo nella libreria di classi .NET Framework. Per usare l'attributo nel codice, è prima necessario definirlo come segue:
namespace System.Runtime
{
[AttributeUsage(AttributeTargets.Method |
AttributeTargets.Constructor |
AttributeTargets.Property)]
public class BypassNGenAttribute : Attribute
{
}
}
Namespace System.Runtime
<AttributeUsage(AttributeTargets.Method Or
AttributeTargets.Constructor Or
AttributeTargets.Property)>
Public Class BypassNGenAttribute : Inherits Attribute
End Class
End Namespace
È quindi possibile applicare l'attributo in base al metodo. L'esempio seguente indica al generatore di immagini native che non deve generare un'immagine nativa per il ExampleClass.ToJITCompile metodo .
using System;
using System.Runtime;
public class ExampleClass
{
[BypassNGen]
public void ToJITCompile()
{
}
}
Imports System.Runtime
Public Class ExampleClass
<BypassNGen>
Public Sub ToJITCompile()
End Sub
End Class
Esempi
Il comando seguente genera un'immagine nativa per ClientApp.exe, che si trova nella directory corrente e installa l'immagine nella cache delle immagini native. Se esiste un file di configurazione per l'assembly, Ngen.exe lo usa. Inoltre, le immagini native vengono generate per tutti i file di .dll a cui ClientApp.exe fa riferimento.
ngen install ClientApp.exe
Un'immagine installata con Ngen.exe è detta anche radice. Una radice può essere un'applicazione o un componente condiviso.
Il comando seguente genera un'immagine nativa per MyAssembly.exe con il percorso specificato.
ngen install c:\myfiles\MyAssembly.exe
Quando si individuano assembly e le relative dipendenze, Ngen.exe usa la stessa logica di probe usata da Common Language Runtime. Per impostazione predefinita, la directory che contiene ClientApp.exe viene usata come directory di base dell'applicazione e il probe di tutti gli assembly inizia in questa directory. È possibile eseguire l'override di questo comportamento usando l'opzione /AppBase .
Annotazioni
Si tratta di una modifica dal comportamento di Ngen.exe in .NET Framework versioni 1.0 e 1.1, in cui la base dell'applicazione è impostata sulla directory corrente.
Un assembly può avere una dipendenza senza un riferimento, ad esempio se carica un file .dll usando il Assembly.Load metodo . È possibile creare un'immagine nativa per un file .dll usando le informazioni di configurazione per l'assembly dell'applicazione, con l'opzione /ExeConfig . Il comando seguente genera un'immagine nativa per MyLib.dll l'uso delle informazioni di configurazione da MyApp.exe.
ngen install c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe
Gli assembly installati in questo modo non vengono rimossi quando l'applicazione viene rimossa.
Per disinstallare una dipendenza, usare le stesse opzioni della riga di comando usate per installarla. Il comando seguente disinstalla l'oggetto MyLib.dll dall'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, usare il nome visualizzato dell'assembly. Per esempio:
ngen install "ClientApp, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"
NGen.exe genera un set separato di immagini per ogni scenario installato. Ad esempio, i comandi seguenti installano un set completo di immagini native per il normale funzionamento, un altro set completo per il debug e un terzo per la profilatura:
ngen install MyApp.exe
ngen install MyApp.exe /debug
ngen install MyApp.exe /profile
Visualizzazione della cache di immagini native
Una volta installate le immagini native nella cache, possono essere visualizzate usando Ngen.exe. Il comando seguente visualizza tutte le immagini native nella cache delle immagini native.
ngen display
L'azione display elenca prima tutti gli assembly radice, seguito da un elenco di tutte le immagini native nel computer.
Usare il nome semplice di un assembly per visualizzare informazioni solo per l'assembly. Il comando seguente visualizza tutte le immagini native nella cache delle immagini native che corrispondono al nome MyAssemblyparziale , alle relative dipendenze e a tutte le radici che hanno una dipendenza da MyAssembly:
ngen display MyAssembly
Conoscere le radici che dipendono da un assembly di componenti condivisi è utile per valutare l'impatto di un'azione update dopo l'aggiornamento del componente condiviso.
Se si specifica l'estensione di file di un assembly, è necessario specificare il percorso o eseguire Ngen.exe dalla directory contenente l'assembly:
ngen display c:\myApps\MyAssembly.exe
Il comando seguente visualizza tutte le immagini native nella cache delle immagini native con il nome MyAssembly e la versione 1.0.0.0.
ngen display "myAssembly, version=1.0.0.0"
Aggiornamento delle immagini
Le immagini vengono in genere aggiornate dopo l'aggiornamento di un componente condiviso. Per aggiornare tutte le immagini native modificate o le cui dipendenze sono state modificate, usare l'azione update senza argomenti.
ngen update
L'aggiornamento di tutte le immagini può essere un processo lungo. È possibile accodamento degli aggiornamenti per l'esecuzione da parte del servizio immagini nativo usando l'opzione /queue . Per altre informazioni sulle priorità di /queue opzione e installazione, vedere Servizio immagini native.
ngen update /queue
Disinstallazione di immagini
Ngen.exe mantiene un elenco di dipendenze, in modo che i componenti condivisi vengano rimossi solo quando tutti gli assembly che dipendono da essi sono stati rimossi. Inoltre, un componente condiviso non viene rimosso se è stato installato come radice.
Il comando seguente disinstalla tutti gli scenari per la radice ClientApp.exe:
ngen uninstall ClientApp
L'azione uninstall può essere usata per rimuovere scenari specifici. Il comando seguente disinstalla tutti gli scenari di debug per ClientApp.exe:
ngen uninstall ClientApp /debug
Annotazioni
La disinstallazione degli /debug scenari non disinstalla uno scenario che include sia /profile che /debug.
Il comando seguente disinstalla tutti gli scenari per una versione specifica di ClientApp.exe:
ngen uninstall "ClientApp, Version=1.0.0.0"
I comandi seguenti disinstallano tutti gli scenari per "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"o solo lo scenario di debug per l'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 per l'azione, specificare un'estensione richiede l'esecuzione install di Ngen.exe dalla directory contenente l'assembly o specificando un percorso completo.
Per esempi relativi al servizio immagini nativo, vedere Servizio immagini native.
Attività Immagine nativa
L'attività immagine nativa è un'attività di Windows che genera e gestisce immagini native. L'attività immagine nativa genera e recupera automaticamente le immagini native per gli scenari supportati. Consente inoltre ai programmi di installazione di usare Ngen.exe (Generatore di immagini native) per creare e aggiornare immagini native in un momento posticipato.
L'attività di immagine nativa viene registrata una sola volta per ogni architettura della CPU supportata in un computer, per consentire la compilazione per le applicazioni destinate a ogni architettura:
| Nome attività | Computer a 32 bit | Computer a 64 bit |
|---|---|---|
| NET Framework NGEN v4.0.30319 | Yes | Yes |
| NET Framework NGEN v4.0.30319 64 | NO | Yes |
L'attività di immagine nativa è disponibile in .NET Framework 4.5 e versioni successive, se in esecuzione in Windows 8 o versioni successive. Nelle versioni precedenti di Windows, .NET Framework usa il servizio immagini native.
Durata attività
In generale, l'Utilità di pianificazione di Windows avvia l'attività di immagine nativa ogni notte quando il computer è inattiva. L'attività controlla qualsiasi lavoro posticipato accodato dai programmi di installazione dell'applicazione, eventuali richieste di aggiornamento delle immagini native posticipate e qualsiasi creazione automatica di immagini. L'attività completa gli elementi di lavoro in sospeso e quindi arresta. Se il computer smette di rimanere inattiva mentre l'attività è in esecuzione, l'attività si arresta.
È anche possibile avviare manualmente l'attività di immagine nativa tramite l'interfaccia utente dell'Utilità di pianificazione o tramite chiamate manuali a NGen.exe. Se l'attività viene avviata tramite uno di questi metodi, continuerà a essere in esecuzione quando il computer non è più inattiva. Le immagini create manualmente usando NGen.exe sono classificate in ordine di priorità per abilitare il comportamento prevedibile per i programmi di installazione dell'applicazione.
Servizio immagini native
Il servizio immagini native è un servizio Windows che genera e gestisce immagini native. Il servizio immagini native consente allo sviluppatore di rinviare l'installazione e l'aggiornamento delle immagini native in periodi in cui il computer è inattiva.
In genere, il servizio immagini nativo viene avviato dal programma di installazione (programma di installazione) per un'applicazione o un aggiornamento. Per le azioni con priorità 3, il servizio viene eseguito durante il tempo di inattività nel computer. Il servizio salva lo stato ed è in grado di continuare tramite più riavvii, se necessario. È possibile accodare più compilazioni di immagini.
Il servizio interagisce anche con il comando manuale Ngen.exe. I comandi manuali hanno la precedenza sull'attività in background.
Annotazioni
In Windows Vista il nome visualizzato per il servizio immagini nativo è "Microsoft.NET Framework NGEN v2.0.50727_X86" o "Microsoft.NET Framework NGEN v2.0.50727_X64". In tutte le versioni precedenti di Microsoft Windows il nome è ".NET Runtime Optimization Service v2.0.50727_X86" o ".NET Runtime Optimization Service v2.0.50727_X64".
Avvio di operazioni posticipate
Prima di iniziare un'installazione o un aggiornamento, è consigliabile sospendere il servizio. In questo modo il servizio non viene eseguito mentre il programma di installazione copia i file o inserisce gli assembly nella Global Assembly Cache. La riga di comando seguente Ngen.exe sospende il servizio:
ngen queue pause
Quando tutte le operazioni posticipate sono state accodate, il comando seguente consente al servizio di riprendere:
ngen queue continue
Per rinviare la generazione di immagini native durante l'installazione di una nuova applicazione o quando si aggiorna un componente condiviso, usare l'opzione /queue con le install azioni o update . Le righe di comando seguenti Ngen.exe installano un'immagine nativa per un componente condiviso ed eseguono un aggiornamento di tutte le radici che potrebbero essere state interessate:
ngen install MyComponent /queue
ngen update /queue
L'azione update rigenera tutte le immagini native invalidate, non solo quelle che usano MyComponent.
Se l'applicazione è costituita da molte radici, è possibile controllare la priorità delle azioni posticipate. I comandi seguenti accodano l'installazione di tre radici.
Assembly1 viene installato per primo, senza attendere il tempo di inattività.
Assembly2 viene installato anche senza attendere il tempo di inattività, ma dopo il completamento di tutte le azioni con priorità 1.
Assembly3 viene installato quando il servizio rileva che il computer è inattiva.
ngen install Assembly1 /queue:1
ngen install Assembly2 /queue:2
ngen install Assembly3 /queue:3
È possibile forzare l'esecuzione sincrona delle azioni in coda usando l'azione executeQueuedItems . Se si specifica la priorità facoltativa, questa azione influisce solo sulle azioni in coda con priorità uguale o inferiore. La priorità predefinita è 3, quindi il comando seguente Ngen.exe elabora immediatamente tutte le azioni in coda e non restituisce finché non vengono completate:
ngen executeQueuedItems
I comandi sincroni vengono eseguiti da Ngen.exe e non usano il servizio immagini nativo. È possibile eseguire azioni usando Ngen.exe mentre il servizio immagini nativo è in esecuzione.
Arresto del servizio
Dopo essere stato avviato dall'esecuzione di un comando Ngen.exe che include l'opzione /queue , il servizio viene eseguito in background fino al completamento di tutte le azioni. Il servizio salva lo stato in modo che possa continuare con più riavvii, se necessario. Quando il servizio rileva che non sono presenti altre azioni in coda, reimposta lo stato in modo che non venga riavviato al successivo avvio del computer e quindi si arresta.
Interazione del servizio con i client
In .NET Framework versione 2.0, l'unica interazione con il servizio immagini nativo è tramite lo strumento da riga di comando Ngen.exe. Usare lo strumento da riga di comando negli script di installazione per accodare le azioni per il servizio immagini nativo e interagire con il servizio.