Partager via

Ngen.exe (Générateur d’images natives)

Le générateur d’images natives (Ngen.exe) est un outil qui améliore les performances des applications managées. Ngen.exe crée des images natives, qui sont des fichiers contenant du code ordinateur spécifique au processeur compilé et les installe dans le cache d’images natif sur l’ordinateur local. Le runtime peut utiliser des images natives à partir du cache au lieu d’utiliser le compilateur juste-à-temps (JIT) pour compiler l’assembly d’origine.

Note

Ngen.exe compile des images natives pour les assemblys qui ciblent .NET Framework uniquement. Le générateur d’images natif équivalent pour .NET Core est CrossGen.

Modifications apportées à Ngen.exe dans .NET Framework 4 :

  • Ngen.exe compile désormais les assemblys avec une confiance totale et la stratégie de sécurité d’accès au code (CAS) n’est plus évaluée.

  • Les images natives générées avec Ngen.exe ne peuvent plus être chargées dans des applications qui s’exécutent en confiance partielle.

Modifications apportées à Ngen.exe dans .NET Framework version 2.0 :

  • L’installation d’un assembly installe également ses dépendances, ce qui simplifie la syntaxe de Ngen.exe.

  • Les images natives peuvent désormais être partagées entre les domaines d’application.

  • Une nouvelle action, , updaterecrée des images qui ont été invalidées.

  • Les actions peuvent être différées pour l’exécution par un service qui utilise le temps d’inactivité sur l’ordinateur pour générer et installer des images.

  • Certaines causes d’invalidation d’image ont été éliminées.

Sur Windows 8, voir Tâche d’image native.

Pour plus d’informations sur l’utilisation de Ngen.exe et du service d’images natifs, consultez Native Image Service.

Note

Ngen.exe syntaxe pour les versions 1.0 et 1.1 du .NET Framework sont disponibles dans native Image Generator (Ngen.exe) La syntaxe héritée.

Cet outil est installé automatiquement avec Visual Studio. Pour exécuter l’outil, utilisez l’invite de commandes développeur Visual Studio ou PowerShell pour développeurs Visual Studio.

À l'invite de commandes, tapez :

Syntaxe

ngen action [options]

ngen /? | /help

Actions

Le tableau suivant présente la syntaxe de chaque action. Pour obtenir des descriptions des parties individuelles d’un action, consultez les tables Arguments, Niveaux de priorité, Scénarios et Configurations . Le tableau Options décrit les options commutateurs d’aide et les commutateurs d’aide.

Action Descriptif
install[assemblyNameassemblyPath | ] [scenarios] [config] [/queue[{1|:|23}]] Générez des images natives pour un assembly et ses dépendances et installez les images dans le cache d’images natif.

Si /queue elle est spécifiée, l’action est mise en file d’attente pour le service d’images natif. La priorité par défaut est 3. Consultez la table Niveaux de priorité .
uninstall[assemblyName | assemblyPath] [] [] [scenariosconfig] Supprimez les images natives d’un assembly et ses dépendances du cache d’images natifs.

Pour désinstaller une seule image et ses dépendances, utilisez les mêmes arguments de ligne de commande que ceux utilisés pour installer l’image. Note: À compter de .NET Framework 4, l’action uninstall * n’est plus prise en charge.
update [/queue] Mettez à jour les images natives qui ne sont plus valides.

Si /queue elle est spécifiée, les mises à jour sont mises en file d’attente pour le service d’image natif. Les mises à jour sont toujours planifiées au niveau de la priorité 3, de sorte qu’elles s’exécutent lorsque l’ordinateur est inactif.
display [assemblyName | assemblyPath] Affichez l’état des images natives pour un assembly et ses dépendances.

Si aucun argument n’est fourni, tout ce qui se trouve dans le cache d’images natives s’affiche.
executeQueuedItems [1|2|3]

- ou -

eqi [1|2|3]		 Exécuter des travaux de compilation mis en file d’attente.

Si une priorité est spécifiée, les travaux de compilation avec une priorité supérieure ou égale sont exécutés. Si aucune priorité n’est spécifiée, tous les travaux de compilation en file d’attente sont exécutés.
queue{pause | | continuestatus} Suspendre le service d’image natif, autoriser le service suspendu à continuer ou interroger l’état du service.

Arguments

Argument Descriptif
assemblyName Nom complet de l’assembly. Par exemple : "myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5". Note: Vous pouvez fournir un nom d’assembly partiel, tel que myAssembly, pour les actions et uninstall les display actions.

Un seul assembly peut être spécifié par ligne de commande Ngen.exe.
assemblyPath Chemin explicite de l’assembly. Vous pouvez spécifier un chemin complet ou relatif.

Si vous spécifiez un nom de fichier sans chemin d’accès, l’assembly doit se trouver dans le répertoire actif.

Un seul assembly peut être spécifié par ligne de commande Ngen.exe.

Niveaux de priorité

Priority Descriptif
1 Les images natives sont générées et installées immédiatement, sans attendre le temps d’inactivité.
2 Les images natives sont générées et installées sans attendre le temps d’inactivité, mais une fois toutes les actions de priorité 1 (et leurs dépendances) terminées.
3 Les images natives sont installées lorsque le service d’images natif détecte que l’ordinateur est inactif. Voir Native Image Service.

Scénarios

Scénario Descriptif
/Debug Générez des images natives qui peuvent être utilisées sous un débogueur.
/Profile Générez des images natives qui peuvent être utilisées sous un profileur.
/NoDependencies Générez le nombre minimal d’images natives requises par les options de scénario spécifiées.

Config

Paramétrage Descriptif
/ExeConfig: exePath Utilisez la configuration de l’assembly exécutable spécifié.

Ngen.exe doit prendre les mêmes décisions que le chargeur lors de la liaison à des dépendances. Lorsqu’un composant partagé est chargé au moment de l’exécution, à l’aide de la Load méthode, le fichier de configuration de l’application détermine les dépendances chargées pour le composant partagé, par exemple la version d’une dépendance chargée. Le /ExeConfig commutateur fournit Ngen.exe conseils sur les dépendances qui seraient chargées au moment de l’exécution.
/AppBase: directoryPath Lors de la localisation des dépendances, utilisez le répertoire spécifié comme base d’application.

Options

Choix Descriptif
/nologo Supprimez l’affichage de la bannière de démarrage Microsoft.
/silent Supprimez l’affichage des messages de réussite.
/verbose Affichez des informations détaillées pour le débogage.
/help, /? Affichez la syntaxe de commande et les options de la version actuelle.

Remarques

Pour exécuter Ngen.exe, vous devez disposer de privilèges d’administration.

Caution

N’exécutez pas Ngen.exe sur les assemblys qui ne sont pas entièrement approuvés. À compter de .NET Framework 4, Ngen.exe compile les assemblys avec une confiance totale et la stratégie de sécurité d’accès au code (CAS) n’est plus évaluée.

À compter de .NET Framework 4, les images natives générées avec Ngen.exe ne peuvent plus être chargées dans des applications qui s’exécutent en confiance partielle. Au lieu de cela, le compilateur juste-à-temps (JIT) est appelé.

Ngen.exe génère des images natives pour l’assembly spécifié par l’argument assemblyname à l’action install et à toutes ses dépendances. Les dépendances sont déterminées à partir de références dans le manifeste d’assembly. Le seul scénario dans lequel vous devez installer une dépendance séparément est le moment où l’application la charge à l’aide de la réflexion, par exemple en appelant la Assembly.Load méthode.

Important

N’utilisez pas la Assembly.LoadFrom méthode avec des images natives. Une image chargée avec cette méthode ne peut pas être utilisée par d’autres assemblys dans le contexte d’exécution.

Ngen.exe conserve un nombre de dépendances. Par exemple, supposons MyAssembly.exe que YourAssembly.exe les deux soient installés dans le cache d’images natifs, et que les deux aient des références à OurDependency.dll. Si MyAssembly.exe elle est désinstallée, OurDependency.dll n’est pas désinstallée. Elle est supprimée uniquement quand YourAssembly.exe elle est également désinstallée.

Si vous générez une image native pour un assembly dans le Global Assembly Cache, spécifiez son nom complet. Voir Assembly.FullName.

Les images natives générées par Ngen.exe peuvent être partagées entre les domaines d’application. Cela signifie que vous pouvez utiliser Ngen.exe dans les scénarios d’application qui nécessitent que les assemblys soient partagés entre les domaines d’application. Pour spécifier la neutralité du domaine :

Utilisez toujours le code neutre du domaine lors du chargement du même assembly dans plusieurs domaines d’application. Si une image native est chargée dans un domaine d’application non partagé après avoir été chargée dans un domaine partagé, elle ne peut pas être utilisée.

Note

Le code neutre du domaine ne peut pas être déchargé et les performances peuvent être légèrement plus lentes, en particulier lors de l’accès aux membres statiques.

Dans cette section Remarques :

Génération d’images pour différents scénarios

Une fois que vous avez généré une image native pour un assembly, le runtime tente automatiquement de localiser et d’utiliser cette image native chaque fois qu’elle exécute l’assembly. Plusieurs images peuvent être générées, en fonction des scénarios d’utilisation.

Par exemple, si vous exécutez un assembly dans un scénario de débogage ou de profilage, le runtime recherche une image native générée avec les options ou /Profile les /Debug options. S’il n’est pas en mesure de trouver une image native correspondante, le runtime revient à la compilation JIT standard. La seule façon de déboguer des images natives consiste à créer une image native avec l’option /Debug .

L’action reconnaît également les scénarios. Vous uninstall pouvez donc désinstaller tous les scénarios ou uniquement les scénarios sélectionnés.

Détermination du moment où utiliser des images natives

Les images natives peuvent améliorer les performances dans deux domaines : une utilisation améliorée de la mémoire et une réduction du temps de démarrage.

Note

Les performances des images natives dépendent d’un certain nombre de facteurs qui rendent l’analyse difficile, comme le code et les modèles d’accès aux données, le nombre d’appels effectués entre les limites du module et le nombre de dépendances déjà chargées par d’autres applications. La seule façon de déterminer si les images natives bénéficient à votre application consiste à effectuer des mesures de performances minutieuses dans vos scénarios de déploiement clés.

Utilisation améliorée de la mémoire

Les images natives peuvent améliorer considérablement l’utilisation de la mémoire lorsque le code est partagé entre les processus. Les images natives sont des fichiers Windows PE, de sorte qu’une copie unique d’un fichier .dll peut être partagée par plusieurs processus ; en revanche, le code natif généré par le compilateur JIT est stocké dans la mémoire privée et ne peut pas être partagé.

Les applications exécutées sous les services terminal peuvent également tirer parti des pages de code partagées.

En outre, le fait de ne pas charger le compilateur JIT enregistre une quantité fixe de mémoire pour chaque instance d’application.

Démarrage plus rapide de l’application

La précompilation des assemblys avec Ngen.exe peut améliorer le temps de démarrage de certaines applications. En général, les gains peuvent être réalisés lorsque les applications partagent des assemblys de composants, car une fois la première application démarrée, les composants partagés sont déjà chargés pour les applications suivantes. Le démarrage à froid, dans lequel tous les assemblys d’une application doivent être chargés à partir du disque dur, ne bénéficie pas autant des images natives, car le temps d’accès au disque dur prédomine.

La liaison difficile peut affecter le temps de démarrage, car toutes les images liées à l’assembly d’application principal doivent être chargées en même temps.

Note

Avant le Service Pack 1 .NET Framework 3.5, vous devez placer des composants partagés et nommés forts dans le Global Assembly Cache, car le chargeur effectue une validation supplémentaire sur des assemblys nommés forts qui ne se trouvent pas dans le Global Assembly Cache, éliminant efficacement toute amélioration du temps de démarrage obtenu à l’aide d’images natives. Les optimisations introduites dans .NET Framework 3.5 SP1 ont supprimé la validation supplémentaire.

Résumé des considérations relatives à l’utilisation

Les considérations générales suivantes et les considérations relatives à l’application peuvent vous aider à décider s’il faut entreprendre l’évaluation des images natives pour votre application :

  • Les images natives sont chargées plus rapidement que CIL, car elles éliminent la nécessité de nombreuses activités de démarrage, telles que la compilation JIT et la vérification de la sécurité des types.

  • Les images natives nécessitent un jeu de travail initial plus petit, car il n’est pas nécessaire pour le compilateur JIT.

  • Les images natives activent le partage de code entre les processus.

  • Les images natives nécessitent plus d’espace disque que les assemblys CIL et peuvent nécessiter beaucoup de temps pour générer.

  • Les images natives doivent être conservées.

    • Les images doivent être régénérées lorsque l’assembly d’origine ou l’une de ses dépendances est servicené.

    • Un seul assembly peut avoir besoin de plusieurs images natives pour une utilisation dans différentes applications ou différents scénarios. Par exemple, les informations de configuration dans deux applications peuvent entraîner des décisions de liaison différentes pour le même assembly dépendant.

    • Les images natives doivent être générées par un administrateur ; autrement dit, à partir d’un compte Windows dans le groupe Administrateurs.

En plus de ces considérations générales, la nature de votre application doit être prise en compte pour déterminer si les images natives peuvent offrir un avantage en matière de performances :

  • Si votre application s’exécute dans un environnement qui utilise de nombreux composants partagés, les images natives permettent aux composants d’être partagés par plusieurs processus.

  • Si votre application utilise plusieurs domaines d’application, les images natives autorisent le partage des pages de code entre les domaines.

    Note

    Dans les versions 1.0 et 1.1 du .NET Framework, les images natives ne peuvent pas être partagées entre les domaines d’application. Ce n’est pas le cas dans la version 2.0 ou ultérieure.

  • Si votre application est exécutée sous Terminal Server, les images natives autorisent le partage de pages de code.

  • Les grandes applications bénéficient généralement de la compilation vers des images natives. Les petites applications ne bénéficient généralement pas.

  • Pour les applications de longue durée, la compilation JIT runtime s’effectue légèrement mieux que les images natives. (La liaison dure peut atténuer cette différence de performances à un certain degré.)

Importance des adresses de base d’assembly

Étant donné que les images natives sont des fichiers Windows PE, elles sont soumises aux mêmes problèmes de rebasing que d’autres fichiers exécutables. Le coût de la réinstallation est encore plus prononcé si la liaison dure est employée.

Pour définir l’adresse de base d’une image native, utilisez l’option appropriée de votre compilateur pour définir l’adresse de base de l’assembly. Ngen.exe utilise cette adresse de base pour l’image native.

Note

Les images natives sont supérieures aux assemblys managés à partir desquels elles ont été créées. Les adresses de base doivent être calculées pour permettre ces tailles plus grandes.

Vous pouvez utiliser un outil tel que dumpbin.exe pour afficher l’adresse de base préférée d’une image native.

Liaison matérielle

La liaison dure augmente le débit et réduit la taille des ensembles de travail pour les images natives. L’inconvénient de la liaison matérielle est que toutes les images liées à un assembly doivent être chargées lorsque l’assembly est chargé. Cela peut augmenter considérablement le temps de démarrage d’une grande application.

La liaison matérielle est appropriée pour les dépendances chargées dans tous les scénarios critiques de performances de votre application. Comme pour n’importe quel aspect de l’utilisation de l’image native, les mesures de performances minutieuses sont la seule façon de déterminer si la liaison dure améliore les performances de votre application.

Les DependencyAttribute attributs et DefaultDependencyAttribute les attributs vous permettent de fournir des indicateurs de liaison durs pour Ngen.exe.

Note

Ces attributs sont des indicateurs pour Ngen.exe, et non pour les commandes. L’utilisation de ces éléments ne garantit pas une liaison matérielle. La signification de ces attributs peut changer dans les versions ultérieures.

Spécification d’un indicateur de liaison pour une dépendance

Appliquez le DependencyAttribute fichier à un assembly pour indiquer la probabilité qu’une dépendance spécifiée soit chargée. LoadHint.Always indique que la liaison matérielle est appropriée, Default indique que la valeur par défaut de la dépendance doit être utilisée et Sometimes indique que la liaison matérielle n’est pas appropriée.

Le code suivant montre les attributs d’un assembly qui a deux dépendances. La première dépendance (Assembly1) est un candidat approprié pour la liaison matérielle, et le second (Assembly2) n’est pas.

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)];

Le nom de l’assembly n’inclut pas l’extension de nom de fichier. Les noms d’affichage peuvent être utilisés.

Spécification d’un indicateur de liaison par défaut pour un assembly

Les indicateurs de liaison par défaut sont uniquement nécessaires pour les assemblys qui seront utilisés immédiatement et fréquemment par toute application qui a une dépendance sur eux. Appliquez la DefaultDependencyAttribute valeur avec LoadHint.Always à ces assemblys pour spécifier que la liaison matérielle doit être utilisée.

Note

Il n’existe aucune raison de s’appliquer DefaultDependencyAttribute à .dll assemblys qui ne appartiennent pas à cette catégorie, car l’application de l’attribut avec une valeur autre que LoadHint.Always n’a pas le même effet que l’application de l’attribut du tout.

Microsoft utilise la spécification que la DefaultDependencyAttribute liaison matérielle est la valeur par défaut d’un très petit nombre d’assemblys dans le .NET Framework, comme mscorlib.dll.

Traitement différé

La génération d’images natives pour une application très volumineuse peut prendre beaucoup de temps. De même, les modifications apportées à un composant partagé ou aux modifications apportées aux paramètres ordinateur peuvent nécessiter la mise à jour de nombreuses images natives. Les actions et update les install actions ont une /queue option qui met en file d’attente l’opération pour l’exécution différée par le service d’image natif. En outre, Ngen.exe a queue et executeQueuedItems des actions qui fournissent un certain contrôle sur le service. Pour plus d’informations, consultez Native Image Service.

Images natives et compilation JIT

Si Ngen.exe rencontre des méthodes dans un assembly qu’il ne peut pas générer, elle les exclut de l’image native. Lorsque le runtime exécute cet assembly, il rétablit la compilation JIT pour les méthodes qui n’ont pas été incluses dans l’image native.

En outre, les images natives ne sont pas utilisées si l’assembly a été mis à niveau ou si l’image a été invalidée pour une raison quelconque.

Images non valides

Lorsque vous utilisez Ngen.exe pour créer une image native d’un assembly, la sortie dépend des options de ligne de commande que vous spécifiez et de certains paramètres sur votre ordinateur. Les paramètres suivants sont inclus :

  • Version de .NET Framework.

  • Identité exacte de l’assembly (la recompilation change l’identité).

  • Identité exacte de tous les assemblys référencés par l’assembly (la recompilation modifie l’identité).

  • Facteurs de sécurité.

Ngen.exe enregistre ces informations lorsqu’elles génèrent une image native. Lorsque vous exécutez un assembly, le runtime recherche l’image native générée avec des options et des paramètres qui correspondent à l’environnement actuel de l’ordinateur. Le runtime revient à la compilation JIT d’un assembly s’il ne trouve pas d’image native correspondante. Les modifications suivantes apportées aux paramètres et à l’environnement d’un ordinateur entraînent l’invalidation des images natives :

  • Version de .NET Framework.

    Si vous appliquez une mise à jour à .NET Framework, toutes les images natives que vous avez créées à l’aide de Ngen.exe deviennent non valides. Pour cette raison, toutes les mises à jour de .NET Framework exécutent la Ngen Update commande pour vous assurer que toutes les images natives sont régénérées. .NET Framework crée automatiquement de nouvelles images natives pour les bibliothèques .NET Framework qu’il installe.

  • Identité exacte de l’assembly.

    Si vous recompilez un assembly, l’image native correspondante de l’assembly devient non valide.

  • Identité exacte des assemblys référencés par l’assembly.

    Si vous mettez à jour un assembly managé, toutes les images natives qui dépendent directement ou indirectement de cet assembly deviennent non valides et doivent être régénérées. Cela inclut les références ordinaires et les dépendances liées en dur. Chaque fois qu’une mise à jour logicielle est appliquée, le programme d’installation doit exécuter une Ngen Update commande pour s’assurer que toutes les images natives dépendantes sont régénérées.

  • Facteurs de sécurité.

    La modification de la stratégie de sécurité de l’ordinateur pour restreindre les autorisations précédemment accordées à un assembly peut entraîner la compilation d’une image native précédemment compilée pour que cet assembly ne devienne pas valide.

    Pour plus d’informations sur la façon dont le Common Language Runtime administre la sécurité de l’accès au code et comment utiliser des autorisations, consultez Sécurité de l’accès au code.

Résolution des problèmes

Les rubriques de résolution des problèmes suivantes vous permettent de voir quelles images natives sont utilisées et qui ne peuvent pas être utilisées par votre application, pour déterminer quand le compilateur JIT commence à compiler une méthode et montre comment refuser la compilation d’images natives des méthodes spécifiées.

Visionneuse du journal de liaison d’assembly

Pour vérifier que les images natives sont utilisées par votre application, vous pouvez utiliser la Fuslogvw.exe (Visionneuse du journal de liaison d’assembly). Sélectionnez Images natives dans la zone Catégories de journaux dans la fenêtre visionneuse de journal de liaison. Fuslogvw.exe fournit des informations sur la raison pour laquelle une image native a été rejetée.

Assistant Débogage managé JITCompilationStart

Vous pouvez utiliser l’Assistant débogage managé jitCompilationStart (MDA) pour déterminer quand le compilateur JIT commence à compiler une fonction.

Désactivation de la génération d’images natives

Dans certains cas, NGen.exe peut avoir des difficultés à générer une image native pour une méthode spécifique, ou vous préférez peut-être que la méthode soit compilée JIT plutôt que compilée sur une image native. Dans ce cas, vous pouvez utiliser l’attribut System.Runtime.BypassNGenAttribute pour empêcher NGen.exe de générer une image native pour une méthode particulière. L’attribut doit être appliqué individuellement à chaque méthode dont vous ne souhaitez pas inclure le code dans l’image native. NGen.exe reconnaît l’attribut et ne génère pas de code dans l’image native pour la méthode correspondante.

Notez toutefois qu’il BypassNGenAttribute n’est pas défini comme un type dans la bibliothèque de classes .NET Framework. Pour consommer l’attribut dans votre code, vous devez d’abord le définir comme suit :

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

Vous pouvez ensuite appliquer l’attribut par méthode. L’exemple suivant indique au générateur d’images native qu’il ne doit pas générer d’image native pour la ExampleClass.ToJITCompile méthode.

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

Examples

La commande suivante génère une image native pour ClientApp.exe, située dans le répertoire actif et installe l’image dans le cache d’images native. Si un fichier de configuration existe pour l’assembly, Ngen.exe l’utilise. En outre, les images natives sont générées pour tous les fichiers .dll qui ClientApp.exe font référence.

ngen install ClientApp.exe

Une image installée avec Ngen.exe est également appelée racine. Une racine peut être une application ou un composant partagé.

La commande suivante génère une image native pour MyAssembly.exe laquelle le chemin d’accès spécifié est généré.

ngen install c:\myfiles\MyAssembly.exe

Lors de la localisation d’assemblys et de leurs dépendances, Ngen.exe utilise la même logique de détection que celle utilisée par le Common Language Runtime. Par défaut, le répertoire qui contient ClientApp.exe est utilisé comme répertoire de base de l’application et tous les problèmes d’assembly commencent dans ce répertoire. Vous pouvez remplacer ce comportement à l’aide de l’option /AppBase .

Note

Il s’agit d’un changement de comportement Ngen.exe dans les versions .NET Framework 1.0 et 1.1, où la base de l’application est définie sur le répertoire actif.

Un assembly peut avoir une dépendance sans référence, par exemple s’il charge un fichier .dll à l’aide de la Assembly.Load méthode. Vous pouvez créer une image native pour un tel fichier .dll à l’aide d’informations de configuration pour l’assembly d’application, avec l’option /ExeConfig . La commande suivante génère une image native pour MyLib.dll utiliser les informations de configuration à partir de MyApp.exe.

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

Les assemblys installés de cette façon ne sont pas supprimés lorsque l’application est supprimée.

Pour désinstaller une dépendance, utilisez les mêmes options de ligne de commande que celles utilisées pour l’installer. La commande suivante désinstalle l’exemple MyLib.dll précédent.

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

Pour créer une image native pour un assembly dans le Global Assembly Cache, utilisez le nom complet de l’assembly. Par exemple:

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

NGen.exe génère un ensemble distinct d’images pour chaque scénario que vous installez. Par exemple, les commandes suivantes installent un ensemble complet d’images natives pour une opération normale, un autre ensemble complet pour le débogage et un troisième pour le profilage :

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

Affichage du cache d’images natives

Une fois les images natives installées dans le cache, elles peuvent être affichées à l’aide de Ngen.exe. La commande suivante affiche toutes les images natives dans le cache d’images natives.

ngen display

L’action display répertorie d’abord tous les assemblys racines, suivis d’une liste de toutes les images natives sur l’ordinateur.

Utilisez le nom simple d’un assembly pour afficher des informations uniquement pour cet assembly. La commande suivante affiche toutes les images natives dans le cache d’images natives qui correspondent au nom MyAssemblypartiel, à leurs dépendances et à toutes les racines qui ont une dépendance sur MyAssembly:

ngen display MyAssembly

Savoir quelles racines dépendent d’un assembly de composant partagé est utile pour évaluer l’impact d’une update action après la mise à niveau du composant partagé.

Si vous spécifiez l’extension de fichier d’un assembly, vous devez spécifier le chemin d’accès ou exécuter Ngen.exe à partir du répertoire contenant l’assembly :

ngen display c:\myApps\MyAssembly.exe

La commande suivante affiche toutes les images natives dans le cache d’images natives avec le nom MyAssembly et la version 1.0.0.0.

ngen display "myAssembly, version=1.0.0.0"

Mise à jour d’images

Les images sont généralement mises à jour après la mise à niveau d’un composant partagé. Pour mettre à jour toutes les images natives qui ont changé ou dont les dépendances ont changé, utilisez l’action update sans argument.

ngen update

La mise à jour de toutes les images peut être un processus long. Vous pouvez mettre en file d’attente les mises à jour pour l’exécution par le service d’images natif à l’aide de l’option /queue . Pour plus d’informations sur l’option et les /queue priorités d’installation, consultez Native Image Service.

ngen update /queue

Désinstallation d’images

Ngen.exe conserve une liste de dépendances, afin que les composants partagés soient supprimés uniquement lorsque tous les assemblys qui en dépendent ont été supprimés. En outre, un composant partagé n’est pas supprimé s’il a été installé en tant que racine.

La commande suivante désinstalle tous les scénarios de la racine ClientApp.exe:

ngen uninstall ClientApp

L’action uninstall peut être utilisée pour supprimer des scénarios spécifiques. La commande suivante désinstalle tous les scénarios de débogage pour ClientApp.exe:

ngen uninstall ClientApp /debug

Note

Les scénarios de désinstallation /debug ne désinstallent pas un scénario incluant les deux /profile et /debug.

La commande suivante désinstalle tous les scénarios d’une version spécifique de ClientApp.exe:

ngen uninstall "ClientApp, Version=1.0.0.0"

Les commandes suivantes désinstallent tous les scénarios pour "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL", ou simplement le scénario de débogage pour cet 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

Comme pour l’action install , la fourniture d’une extension nécessite l’exécution de Ngen.exe à partir du répertoire contenant l’assembly ou la spécification d’un chemin d’accès complet.

Pour obtenir des exemples relatifs au service d’images natives, consultez Native Image Service.

Tâche d’image native

La tâche d’image native est une tâche Windows qui génère et gère des images natives. La tâche d’image native génère et récupère automatiquement des images natives pour les scénarios pris en charge. Il permet également aux programmes d’installation d’utiliser Ngen.exe (Générateur d’images natives) pour créer et mettre à jour des images natives à un moment différé.

La tâche d’image native est inscrite une fois pour chaque architecture uc prise en charge sur un ordinateur, afin d’autoriser la compilation pour les applications qui ciblent chaque architecture :

Nom de la tâche Ordinateur 32 bits Ordinateur 64 bits
NET Framework NGEN v4.0.30319 Oui Oui
NET Framework NGEN v4.0.30319 64 Non Oui

La tâche d’image native est disponible dans .NET Framework 4.5 et versions ultérieures, lors de l’exécution sur Windows 8 ou version ultérieure. Sur les versions antérieures de Windows, le .NET Framework utilise le service d’image native.

Durée de vie des tâches

En général, le Planificateur de tâches Windows démarre la tâche d’image native chaque nuit lorsque l’ordinateur est inactif. La tâche vérifie tout travail différé mis en file d’attente par les programmes d’installation d’application, toutes les demandes de mise à jour d’images natives différées et toute création automatique d’images. La tâche termine les éléments de travail en attente, puis s’arrête. Si l’ordinateur cesse d’être inactif pendant l’exécution de la tâche, la tâche s’arrête.

Vous pouvez également démarrer la tâche d’image native manuellement via l’interface utilisateur du planificateur de tâches ou par le biais d’appels manuels à NGen.exe. Si la tâche est démarrée par l’une de ces méthodes, elle continue à s’exécuter lorsque l’ordinateur n’est plus inactif. Les images créées manuellement à l’aide de NGen.exe sont hiérarchisées pour activer le comportement prévisible pour les programmes d’installation d’applications.

Service d’images natives

Le service d’images native est un service Windows qui génère et gère des images natives. Le service d’images natives permet au développeur de différer l’installation et la mise à jour des images natives sur des périodes où l’ordinateur est inactif.

Normalement, le service d’image native est lancé par le programme d’installation (programme d’installation) pour une application ou une mise à jour. Pour les actions de priorité 3, le service s’exécute pendant le temps d’inactivité sur l’ordinateur. Le service enregistre son état et est capable de poursuivre plusieurs redémarrages si nécessaire. Plusieurs compilations d’images peuvent être mises en file d’attente.

Le service interagit également avec la commande manuelle Ngen.exe. Les commandes manuelles sont prioritaires sur l’activité en arrière-plan.

Note

Sur Windows Vista, le nom affiché pour le service d’images native est « Microsoft.NET Framework NGEN v2.0.50727_X86 » ou « Microsoft.NET Framework NGEN v2.0.50727_X64 ». Sur toutes les versions antérieures de Microsoft Windows, le nom est « . NET Runtime Optimization Service v2.0.50727_X86 » ou « . NET Runtime Optimization Service v2.0.50727_X64 ».

Lancement d’opérations différées

Avant de commencer une installation ou une mise à niveau, il est recommandé de suspendre le service. Cela garantit que le service ne s’exécute pas pendant que le programme d’installation copie des fichiers ou met des assemblys dans le Global Assembly Cache. La ligne de commande Ngen.exe suivante interrompt le service :

ngen queue pause

Lorsque toutes les opérations différées ont été mises en file d’attente, la commande suivante permet au service de reprendre :

ngen queue continue

Pour différer la génération d’images natives lors de l’installation d’une nouvelle application ou lors de la mise à jour d’un composant partagé, utilisez l’option /queue avec les actions ou update les install actions. Les lignes de commande Ngen.exe suivantes installent une image native pour un composant partagé et effectuent une mise à jour de toutes les racines susceptibles d’avoir été affectées :

ngen install MyComponent /queue
ngen update /queue

L’action update régénère toutes les images natives qui ont été invalidées, pas seulement celles qui utilisent MyComponent.

Si votre application se compose de nombreuses racines, vous pouvez contrôler la priorité des actions différées. Les commandes suivantes filent d’attente l’installation de trois racines. Assembly1 est installé en premier, sans attendre le temps d’inactivité. Assembly2 est également installé sans attendre le temps d’inactivité, mais une fois toutes les actions prioritaires 1 terminées. Assembly3 est installé lorsque le service détecte que l’ordinateur est inactif.

ngen install Assembly1 /queue:1
ngen install Assembly2 /queue:2
ngen install Assembly3 /queue:3

Vous pouvez forcer les actions mises en file d’attente à se produire de manière synchrone à l’aide de l’action executeQueuedItems . Si vous fournissez la priorité facultative, cette action affecte uniquement les actions mises en file d’attente qui ont une priorité égale ou inférieure. La priorité par défaut est 3. Par conséquent, la commande Ngen.exe suivante traite immédiatement toutes les actions mises en file d’attente et ne retourne pas tant qu’elles ne sont pas terminées :

ngen executeQueuedItems

Les commandes synchrones sont exécutées par Ngen.exe et n’utilisent pas le service d’image natif. Vous pouvez exécuter des actions à l’aide de Ngen.exe pendant l’exécution du service d’images natif.

Arrêt du service

Après avoir été lancé par l’exécution d’une commande Ngen.exe qui inclut l’option /queue , le service s’exécute en arrière-plan jusqu’à ce que toutes les actions soient terminées. Le service enregistre son état afin qu’il puisse passer par plusieurs redémarrages si nécessaire. Lorsque le service détecte qu’il n’y a plus d’actions mises en file d’attente, il réinitialise son état afin qu’il ne redémarre pas la prochaine fois que l’ordinateur est démarré, puis s’arrête lui-même.

Interaction de service avec les clients

Dans .NET Framework version 2.0, la seule interaction avec le service d’images natif est via l’outil en ligne de commande Ngen.exe. Utilisez l’outil en ligne de commande dans les scripts d’installation pour mettre en file d’attente les actions du service d’image natif et interagir avec le service.

Voir aussi

  • Last updated on