Ngen.exe (Native Image Generator)

Der native Image-Generator (Ngen.exe) ist ein Tool, das die Leistung verwalteter Anwendungen verbessert. Ngen.exe erstellt systemeigene Images, bei denen es sich um Dateien handelt, die kompilierten prozessorspezifischen Computercode enthalten, und installiert sie im nativen Imagecache auf dem lokalen Computer. Die Laufzeit kann systemeigene Images aus dem Cache verwenden, anstatt den Just-in-Time-Compiler (JIT) zum Kompilieren der ursprünglichen Assembly zu verwenden.

Hinweis

Ngen.exe kompiliert systemeigene Images nur für Assemblys, die auf .NET Framework abzielen. Der entsprechende native Image-Generator für .NET Core ist CrossGen.

Änderungen an Ngen.exe in .NET Framework 4:

• Ngen.exe kompiliert jetzt Assemblys mit voller Vertrauenswürdigheit, und die Cas-Richtlinie (Code Access Security) wird nicht mehr ausgewertet.

• Systemeigene Bilder, die mit Ngen.exe generiert werden, können nicht mehr in Anwendungen geladen werden, die teilweise vertrauenswürdig ausgeführt werden.

Änderungen an Ngen.exe in .NET Framework, Version 2.0:

• Durch die Installation einer Assembly werden auch die Abhängigkeiten installiert und die Syntax von Ngen.exevereinfacht.

• Systemeigene Bilder können jetzt über Anwendungsdomänen hinweg freigegeben werden.

• Eine neue Aktion , updateerstellt erneut Bilder, die ungültig wurden.

• Aktionen können für die Ausführung durch einen Dienst zurückgestellt werden, der Leerlaufzeit auf dem Computer verwendet, um Images zu generieren und zu installieren.

• Einige Ursachen für die Ungültigkeit von Bildern wurden beseitigt.

Unter Windows 8 finden Sie Informationen zur systemeigenen Imageaufgabe.

Weitere Informationen zur Verwendung von Ngen.exe und dem systemeigenen Imagedienst finden Sie unter Native Image Service.

Hinweis

Ngen.exe Syntax für die Versionen 1.0 und 1.1 von .NET Framework finden Sie unter native Image Generator (Ngen.exe) Legacysyntax.

Dieses Tool wird automatisch mit Visual Studio installiert. Um das Tool auszuführen, verwenden Sie die Developer-Eingabeaufforderung von Visual Studio oder Visual Studio Developer PowerShell.

Geben Sie an der Eingabeaufforderung Folgendes ein:

Syntax

ngen action [options]

ngen /? | /help

Aktionen

Die folgende Tabelle zeigt die Syntax der einzelnen action. Beschreibungen der einzelnen Teile eines Elements actionfinden Sie in den Tabellen "Argumente", "Prioritätsebenen", " Szenarien" und "Config" . In der Tabelle "Optionen " werden die options Und die Hilfeoptionen beschrieben.

Maßnahme	Description
install[] [assemblyName | assemblyPath] [] [scenarios] [config/queue[{13:|2|}]]	Generieren Sie systemeigene Images für eine Assembly und deren Abhängigkeiten, und installieren Sie die Images im nativen Imagecache. Wenn /queue angegeben, wird die Aktion für den systemeigenen Bilddienst in die Warteschlange gestellt. Die Standardpriorität ist 3. Siehe die Tabelle "Prioritätsebenen ".
uninstall[] [] [assemblyName | assemblyPath] []scenariosconfig	Löschen Sie die systemeigenen Images einer Assembly und deren Abhängigkeiten aus dem nativen Imagecache. Um ein einzelnes Image und dessen Abhängigkeiten zu deinstallieren, verwenden Sie die gleichen Befehlszeilenargumente, die zum Installieren des Images verwendet wurden. Anmerkung: Ab .NET Framework 4 wird die Aktion uninstall * nicht mehr unterstützt.
update [/queue]	Aktualisieren Sie systemeigene Bilder, die ungültig wurden. Wenn /queue angegeben, werden die Updates für den systemeigenen Imagedienst in die Warteschlange gestellt. Updates werden immer mit Priorität 3 geplant, sodass sie ausgeführt werden, wenn der Computer im Leerlauf ist.
display [assemblyName | assemblyPath]	Zeigt den Status der systemeigenen Bilder für eine Assembly und deren Abhängigkeiten an. Wenn kein Argument angegeben wird, wird alles im nativen Bildcache angezeigt.
executeQueuedItems [1|2|3] -oder- eqi [1|2|3]	Führen Sie Warteschlangenkompilierungsaufträge aus. Wenn eine Priorität angegeben ist, werden Kompilierungsaufträge mit höherer oder gleicher Priorität ausgeführt. Wenn keine Priorität angegeben ist, werden alle Kompilierungsaufträge in der Warteschlange ausgeführt.
queue{pause | | continuestatus}	Anhalten des systemeigenen Bilddiensts, Zulassen, dass der angehaltene Dienst fortgesetzt wird, oder fragen Sie den Status des Diensts ab.

Arguments

Argument	Description
assemblyName	Der vollständige Anzeigename der Assembly. Beispiel: "myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5". Anmerkung: Sie können einen Teilassemblynamen angeben, z myAssembly. B. für die display Und uninstall Aktionen. Pro Ngen.exe Befehlszeile kann nur eine Assembly angegeben werden.
assemblyPath	Der explizite Pfad der Assembly. Sie können einen vollständigen oder relativen Pfad angeben. Wenn Sie einen Dateinamen ohne Pfad angeben, muss sich die Assembly im aktuellen Verzeichnis befinden. Pro Ngen.exe Befehlszeile kann nur eine Assembly angegeben werden.

Prioritätsebenen

Priority	Description
1	Systemeigene Images werden sofort generiert und installiert, ohne auf Leerlaufzeit zu warten.
2	Native Images werden generiert und installiert, ohne auf Leerlaufzeit zu warten, aber nachdem alle Aktionen der Priorität 1 (und deren Abhängigkeiten) abgeschlossen wurden.
3	Systemeigene Images werden installiert, wenn der systemeigene Imagedienst erkennt, dass der Computer im Leerlauf ist. Siehe systemeigener Imagedienst.

Szenarien

Scenario	Description
/Debug	Generieren Sie systemeigene Bilder, die unter einem Debugger verwendet werden können.
/Profile	Generieren Sie systemeigene Bilder, die unter einem Profiler verwendet werden können.
/NoDependencies	Generieren Sie die Mindestanzahl systemeigener Bilder, die für die angegebenen Szenariooptionen erforderlich sind.

Konfiguration

Konfiguration	Description
/ExeConfig: exePath	Verwenden Sie die Konfiguration der angegebenen ausführbaren Assembly. Ngen.exe müssen beim Binden an Abhängigkeiten dieselben Entscheidungen treffen wie das Ladeprogramm. Wenn eine freigegebene Komponente zur Laufzeit geladen wird, bestimmt die Load Konfigurationsdatei der Anwendung die Abhängigkeiten, die für die freigegebene Komponente geladen werden, z. B. die Version einer geladenen Abhängigkeit. Die /ExeConfig Option gibt Ngen.exe Anleitungen darüber, welche Abhängigkeiten zur Laufzeit geladen werden.
/AppBase: directoryPath	Verwenden Sie beim Suchen von Abhängigkeiten das angegebene Verzeichnis als Anwendungsbasis.

Options

Option	Description
/nologo	Unterdrücken Sie die Anzeige des Microsoft-Startbanners.
/silent	Unterdrücken der Anzeige von Erfolgsmeldungen.
/verbose	Detaillierte Informationen zum Debuggen anzeigen.
/help, /?	Anzeigen von Befehlssyntax und Optionen für die aktuelle Version.

Bemerkungen

Um Ngen.exeauszuführen, müssen Sie über Administratorrechte verfügen.

Vorsicht

Führen Sie Ngen.exe nicht für Assemblys aus, die nicht vollständig vertrauenswürdig sind. Ab .NET Framework 4 kompiliert Ngen.exe Assemblys mit voller Vertrauenswürdigheit, und die Cas-Richtlinie (Code Access Security) wird nicht mehr ausgewertet.

Ab .NET Framework 4 können die systemeigenen Images, die mit Ngen.exe generiert werden, nicht mehr in Anwendungen geladen werden, die in teilweiser Vertrauensstellung ausgeführt werden. Stattdessen wird der Just-in-Time-Compiler (JIT) aufgerufen.

Ngen.exe generiert systemeigene Bilder für die Assembly, die durch das assemblyname Argument für die install Aktion und alle zugehörigen Abhängigkeiten angegeben wird. Abhängigkeiten werden aus Verweisen im Assemblymanifest bestimmt. Das einzige Szenario, in dem Sie eine Abhängigkeit separat installieren müssen, besteht darin, dass die Anwendung sie mithilfe von Spiegelung lädt, z. B. durch Aufrufen der Assembly.Load Methode.

Von Bedeutung

Verwenden Sie die Assembly.LoadFrom Methode nicht mit systemeigenen Bildern. Ein mit dieser Methode geladenes Bild kann nicht von anderen Assemblys im Ausführungskontext verwendet werden.

Ngen.exe verwaltet eine Anzahl von Abhängigkeiten. Nehmen wir beispielsweise an MyAssembly.exe und YourAssembly.exe sind beide im nativen Imagecache installiert, und beide weisen Verweise auf OurDependency.dll. Wenn MyAssembly.exe sie deinstalliert wird, OurDependency.dll wird sie nicht deinstalliert. Sie wird nur entfernt, wenn YourAssembly.exe sie auch deinstalliert wird.

Wenn Sie ein systemeigenes Image für eine Assembly im globalen Assemblycache generieren, geben Sie den Anzeigenamen an. Siehe Assembly.FullName.

Die systemeigenen Bilder, die Ngen.exe generiert, können über Anwendungsdomänen hinweg freigegeben werden. Dies bedeutet, dass Sie Ngen.exe in Anwendungsszenarien verwenden können, für die Assemblys für alle Anwendungsdomänen freigegeben werden müssen. So geben Sie Domänenneutralität an:

• Wenden Sie das LoaderOptimizationAttribute Attribut auf Ihre Anwendung an.

• Legen Sie die AppDomainSetup.LoaderOptimization Eigenschaft fest, wenn Sie Setupinformationen für eine neue Anwendungsdomäne erstellen.

Verwenden Sie immer domänenneutralen Code, wenn Sie dieselbe Assembly in mehrere Anwendungsdomänen laden. Wenn ein systemeigenes Image nach dem Laden in eine nicht freigegebene Anwendungsdomäne geladen wird, kann es nicht verwendet werden.

Hinweis

Domänenneutraler Code kann nicht entladen werden, und die Leistung kann etwas langsamer sein, insbesondere beim Zugriff auf statische Member.

In diesem Abschnitt "Hinweise":

• Generieren von Bildern für verschiedene Szenarien

• Bestimmen, wann systemeigene Bilder verwendet werden sollen

  • Verbesserte Speichernutzung

  • Schnelleres Starten der Anwendung

  • Zusammenfassung der Überlegungen zur Nutzung

• Wichtigkeit von Assemblybasisadressen

• Harte Bindung

  • Angeben eines Bindungshinweiss für eine Abhängigkeit

  • Angeben eines Standardbindungshinweiss für eine Assembly

• Verzögerte Verarbeitung

• Native Images und JIT-Kompilierung

  • Ungültige Bilder

• Problembehandlung

  • Assemblybindungsprotokollanzeige

  • Der assistent für verwaltetes Debuggen von JITCompilationStart

  • Abmelden der nativen Bildgenerierung

Generieren von Bildern für verschiedene Szenarien

Nachdem Sie ein systemeigenes Image für eine Assembly generiert haben, versucht die Laufzeit bei jeder Ausführung der Assembly automatisch, dieses systemeigene Image zu suchen und zu verwenden. Je nach Nutzungsszenarien können mehrere Bilder generiert werden.

Wenn Sie beispielsweise eine Assembly in einem Debug- oder Profilerstellungsszenario ausführen, sucht die Laufzeit nach einem systemeigenen Image, das mit den /Debug Oder-Optionen /Profile generiert wurde. Wenn kein passendes systemeigenes Image gefunden werden kann, wird die Laufzeit auf die standardmäßige JIT-Kompilierung zurückgesetzt. Die einzige Möglichkeit zum Debuggen systemeigener Bilder besteht darin, ein systemeigenes Image mit der /Debug Option zu erstellen.

Die uninstall Aktion erkennt auch Szenarien, sodass Sie alle Szenarien oder nur ausgewählte Szenarien deinstallieren können.

Bestimmen, wann systemeigene Bilder verwendet werden sollen

Systemeigene Bilder können Leistungsverbesserungen in zwei Bereichen bieten: verbesserte Arbeitsspeichernutzung und reduzierte Startzeit.

Hinweis

Die Leistung systemeigener Bilder hängt von einer Reihe von Faktoren ab, die die Analyse erschweren, z. B. Code- und Datenzugriffsmuster, wie viele Aufrufe über Modulgrenzen hinweg getätigt werden und wie viele Abhängigkeiten bereits von anderen Anwendungen geladen wurden. Die einzige Möglichkeit, zu ermitteln, ob systemeigene Images Ihrer Anwendung zugute kommen, ist eine sorgfältige Leistungsmessung in Ihren wichtigsten Bereitstellungsszenarien.

Verbesserte Speichernutzung

Systemeigene Bilder können die Speichernutzung erheblich verbessern, wenn Code zwischen Prozessen gemeinsam genutzt wird. Native Images sind Windows PE-Dateien, sodass eine einzelne Kopie einer .dll Datei von mehreren Prozessen gemeinsam genutzt werden kann; Im Gegensatz dazu wird vom JIT-Compiler erzeugter systemeigener Code im privaten Speicher gespeichert und kann nicht freigegeben werden.

Anwendungen, die unter Terminaldiensten ausgeführt werden, können auch von freigegebenen Codeseiten profitieren.

Darüber hinaus speichert das Laden des JIT-Compilers für jede Anwendungsinstanz einen festen Arbeitsspeicher.

Schnelleres Starten der Anwendung

Das Vorkompilieren von Assemblys mit Ngen.exe kann die Startzeit für einige Anwendungen verbessern. Im Allgemeinen können Gewinne erzielt werden, wenn Anwendungen Komponentenassemblys freigeben, da nach dem Start der ersten Anwendung die freigegebenen Komponenten bereits für nachfolgende Anwendungen geladen werden. Kaltstart, bei dem alle Assemblys in einer Anwendung von der Festplatte geladen werden müssen, profitiert nicht so viel von systemeigenen Images, da die Festplattenzugriffszeit vorherrscht.

Die feste Bindung kann sich auf die Startzeit auswirken, da alle An die Hauptanwendungsassembly gebundenen Images gleichzeitig geladen werden müssen.

Hinweis

Vor .NET Framework 3.5 Service Pack 1 sollten Sie freigegebene, stark benannte Komponenten im globalen Assemblycache ablegen, da das Ladeprogramm zusätzliche Überprüfungen für stark benannte Assemblys durchführt, die sich nicht im globalen Assemblycache befinden, wodurch eine Verbesserung der Startzeit, die durch die Verwendung systemeigener Images erzielt wird, effektiv eliminiert wird. Optimierungen, die in .NET Framework 3.5 SP1 eingeführt wurden, haben die zusätzliche Überprüfung entfernt.

Zusammenfassung der Überlegungen zur Nutzung

Die folgenden allgemeinen Überlegungen und Anwendungsüberlegungen können Ihnen dabei helfen, zu entscheiden, ob sie sich bemühen, systemeigene Bilder für Ihre Anwendung auszuwerten:

• Systemeigene Bilder werden schneller als CIL geladen, da sie die Notwendigkeit vieler Startaktivitäten wie JIT-Kompilierung und Typsicherheitsüberprüfung vermeiden.

• Systemeigene Bilder erfordern einen kleineren anfänglichen Arbeitssatz, da der JIT-Compiler nicht benötigt wird.

• Systemeigene Bilder ermöglichen die Codefreigabe zwischen Prozessen.

• Systemeigene Images erfordern mehr Festplattenspeicher als CIL-Assemblys und erfordern möglicherweise erhebliche Zeit zum Generieren.

• Systemeigene Bilder müssen beibehalten werden.

  • Bilder müssen neu generiert werden, wenn die ursprüngliche Assembly oder eine ihrer Abhängigkeiten gewartet wird.

  • Eine einzelne Assembly benötigt möglicherweise mehrere systemeigene Images für die Verwendung in verschiedenen Anwendungen oder in verschiedenen Szenarien. Beispielsweise können die Konfigurationsinformationen in zwei Anwendungen zu unterschiedlichen Bindungsentscheidungen für dieselbe abhängige Assembly führen.

  • Systemeigene Bilder müssen von einem Administrator generiert werden; d. h. aus einem Windows-Konto in der Gruppe "Administratoren".

Zusätzlich zu diesen allgemeinen Überlegungen muss die Art der Anwendung berücksichtigt werden, wenn ermittelt wird, ob systemeigene Bilder einen Leistungsvorteil bieten können:

• Wenn Ihre Anwendung in einer Umgebung ausgeführt wird, in der viele freigegebene Komponenten verwendet werden, können systemeigene Images die Komponenten von mehreren Prozessen gemeinsam nutzen.

• Wenn Ihre Anwendung mehrere Anwendungsdomänen verwendet, ermöglichen systemeigene Bilder die Gemeinsame Nutzung von Codeseiten über Domänen hinweg.

  Hinweis

  In den .NET Framework-Versionen 1.0 und 1.1 können systemeigene Images nicht für anwendungsübergreifende Domänen freigegeben werden. Dies ist nicht der Fall in Version 2.0 oder höher.

• Wenn Ihre Anwendung unter Terminal Server ausgeführt wird, ermöglichen systemeigene Bilder die Freigabe von Codeseiten.

• Große Anwendungen profitieren in der Regel von der Kompilierung zu systemeigenen Images. Kleine Anwendungen profitieren in der Regel nicht.

• Bei langwierigen Anwendungen führt die JIT-Laufzeitkompilierung etwas besser aus als systemeigene Images. (Harte Bindung kann diesen Leistungsunterschied in gewissem Maße mindern.)

Wichtigkeit von Assemblybasisadressen

Da es sich bei systemeigenen Images um Windows PE-Dateien handelt, unterliegen sie den gleichen problemen wie andere ausführbare Dateien. Die Leistungskosten des Umzugs sind noch ausgeprägter, wenn hartbindung eingesetzt wird.

Um die Basisadresse für ein systemeigenes Image festzulegen, verwenden Sie die entsprechende Option des Compilers, um die Basisadresse für die Assembly festzulegen. Ngen.exe verwendet diese Basisadresse für das systemeigene Image.

Hinweis

Native Images sind größer als die verwalteten Assemblys, aus denen sie erstellt wurden. Basisadressen müssen berechnet werden, damit diese größeren Größen zulässig sind.

Sie können ein Tool wie dumpbin.exe verwenden, um die bevorzugte Basisadresse eines nativen Bilds anzuzeigen.

Harte Bindung

Die feste Bindung erhöht den Durchsatz und reduziert die Arbeitssatzgröße für systemeigene Bilder. Der Nachteil der harten Bindung besteht darin, dass alle Images, die hart an eine Assembly gebunden sind, geladen werden müssen, wenn die Assembly geladen wird. Dies kann die Startzeit für eine große Anwendung erheblich erhöhen.

Die feste Bindung eignet sich für Abhängigkeiten, die in allen leistungskritischen Szenarien Ihrer Anwendung geladen werden. Wie bei jedem Aspekt der nativen Bildverwendung sind sorgfältige Leistungsmessungen die einzige Möglichkeit, zu bestimmen, ob die harte Bindung die Leistung Ihrer Anwendung verbessert.

DefaultDependencyAttribute Mit DependencyAttribute den Attributen können Sie harte Bindungshinweise für Ngen.exebereitstellen.

Hinweis

Diese Attribute sind Hinweise auf Ngen.exeund keine Befehle. Die Verwendung garantiert keine harte Bindung. Die Bedeutung dieser Attribute kann sich in zukünftigen Versionen ändern.

Angeben eines Bindungshinweiss für eine Abhängigkeit

Wenden Sie die DependencyAttribute Assembly an, um die Wahrscheinlichkeit anzugeben, dass eine angegebene Abhängigkeit geladen wird. LoadHint.Always gibt an, dass eine feste Bindung geeignet ist, gibt an, Default dass die Standardeinstellung für die Abhängigkeit verwendet werden soll, und Sometimes gibt an, dass eine feste Bindung nicht geeignet ist.

Der folgende Code zeigt die Attribute für eine Assembly mit zwei Abhängigkeiten. Die erste Abhängigkeit (Assembly1) ist ein geeigneter Kandidat für die harte Bindung, und die zweite (Assembly2) ist nicht.

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

Der Assemblyname enthält nicht die Dateinamenerweiterung. Anzeigenamen können verwendet werden.

Angeben eines Standardbindungshinweiss für eine Assembly

Standardbindungshinweise sind nur für Assemblys erforderlich, die von jeder Anwendung, die von ihnen abhängig ist, sofort und häufig verwendet werden. Wenden Sie die DefaultDependencyAttribute Verbindung auf LoadHint.Always solche Assemblys an, um anzugeben, dass eine feste Bindung verwendet werden soll.

Hinweis

Es gibt keinen Grund, auf .dll Assemblys anzuwenden DefaultDependencyAttribute , die nicht in diese Kategorie fallen, da das Anwenden des Attributs mit einem anderen Wert als LoadHint.Always dem gleichen Effekt wie das Anwenden des Attributs überhaupt nicht hat.

Microsoft verwendet die DefaultDependencyAttribute Angabe, dass die feste Bindung die Standardeinstellung für eine sehr kleine Anzahl von Assemblys in .NET Framework ist, z. B. mscorlib.dll.

Verzögerte Verarbeitung

Die Generierung von nativen Bildern für eine sehr große Anwendung kann erhebliche Zeit in Anspruch nehmen. Ebenso müssen Änderungen an einer freigegebenen Komponente oder Änderungen an computereinstellungen viele systemeigene Bilder aktualisiert werden. Die install Und update Aktionen haben eine /queue Option, die den Vorgang für die verzögerte Ausführung durch den systemeigenen Imagedienst in die Warteschlange stellt. Darüber hinaus verfügt Ngen.exe über queue und executeQueuedItems Aktionen, die eine gewisse Kontrolle über den Dienst bieten. Weitere Informationen finden Sie unter Native Image Service.

Native Images und JIT-Kompilierung

Wenn Ngen.exe auf Methoden in einer Assembly stoßen, die nicht generiert werden können, schließt sie sie aus dem systemeigenen Image aus. Wenn die Laufzeit diese Assembly ausführt, wird sie auf die JIT-Kompilierung für die Methoden zurückgesetzt, die nicht im systemeigenen Image enthalten waren.

Darüber hinaus werden systemeigene Images nicht verwendet, wenn die Assembly aktualisiert wurde oder das Image aus irgendeinem Grund ungültig wurde.

Ungültige Bilder

Wenn Sie Ngen.exe verwenden, um ein systemeigenes Image einer Assembly zu erstellen, hängt die Ausgabe von den Befehlszeilenoptionen ab, die Sie angeben und bestimmte Einstellungen auf Ihrem Computer festlegen. Dazu gehören folgende Einstellungen:

• Die Version von .NET Framework.

• Die genaue Identität der Assembly (Die Identität der Neukompilierung ändert die Identität).

• Die genaue Identität aller Assemblys, auf die die Assembly verweist (Neukompilierung ändert die Identität).

• Sicherheitsfaktoren.

Ngen.exe zeichnet diese Informationen auf, wenn sie ein systemeigenes Bild generiert. Wenn Sie eine Assembly ausführen, sucht die Laufzeit nach dem systemeigenen Image, das mit Optionen und Einstellungen generiert wird, die der aktuellen Umgebung des Computers entsprechen. Die Laufzeit wird auf die JIT-Kompilierung einer Assembly zurückgesetzt, wenn kein passendes systemeigenes Image gefunden wird. Die folgenden Änderungen an den Einstellungen und der Umgebung eines Computers führen dazu, dass systemeigene Bilder ungültig werden:

• Die Version von .NET Framework.

  Wenn Sie ein Update auf .NET Framework anwenden, werden alle systemeigenen Images, die Sie mit Ngen.exe erstellt haben, ungültig. Aus diesem Grund führen alle Updates von .NET Framework den Ngen Update Befehl aus, um sicherzustellen, dass alle systemeigenen Images neu generiert werden. .NET Framework erstellt automatisch neue native Images für die .NET Framework-Bibliotheken, die installiert werden.

• Die genaue Identität der Assembly.

  Wenn Sie eine Assembly neu kompilieren, wird das entsprechende systemeigene Image der Assembly ungültig.

• Die genaue Identität aller Assemblys, auf die die Assemblyverweise verweist.

  Wenn Sie eine verwaltete Assembly aktualisieren, werden alle systemeigenen Images, die direkt oder indirekt von dieser Assembly abhängen, ungültig und müssen neu generiert werden. Dazu gehören sowohl gewöhnliche Bezüge als auch feste Abhängigkeiten. Wenn ein Softwareupdate angewendet wird, sollte das Installationsprogramm einen Ngen Update Befehl ausführen, um sicherzustellen, dass alle abhängigen nativen Images neu generiert werden.

• Sicherheitsfaktoren.

  Das Ändern der Computersicherheitsrichtlinie zum Einschränken von Berechtigungen, die zuvor einer Assembly erteilt wurden, kann dazu führen, dass ein zuvor kompiliertes systemeigenes Image für diese Assembly ungültig wird.

  Ausführliche Informationen dazu, wie die Common Language Runtime Die Codezugriffssicherheit verwaltet und wie Berechtigungen verwendet werden, finden Sie unter Code Access Security.

Problembehandlung

In den folgenden Themen zur Problembehandlung können Sie sehen, welche systemeigenen Bilder verwendet werden und welche nicht von Ihrer Anwendung verwendet werden können, um zu bestimmen, wann der JIT-Compiler mit der Kompilierung einer Methode beginnt, und zeigt, wie Sie die systemeigene Bildkompilierung der angegebenen Methoden deaktivieren.

Assemblybindungsprotokollanzeige

Um zu bestätigen, dass systemeigene Bilder von Ihrer Anwendung verwendet werden, können Sie den Fuslogvw.exe (Assembly Binding Log Viewer) verwenden. Wählen Sie " Native Bilder " im Feld "Protokollkategorien " im Fenster "Bindungsprotokollanzeige" aus. Fuslogvw.exe enthält Informationen dazu, warum ein systemeigenes Bild abgelehnt wurde.

Der assistent für verwaltetes Debuggen von JITCompilationStart

Sie können den jitCompilationStart Managed Debugging Assistant (MDA) verwenden, um zu bestimmen, wann der JIT-Compiler beginnt, eine Funktion zu kompilieren.

Abmelden der nativen Bildgenerierung

In einigen Fällen kann NGen.exe Schwierigkeiten haben, ein systemeigenes Bild für eine bestimmte Methode zu generieren, oder Sie bevorzugen es, dass die Methode JIT kompiliert wird, anstatt in ein systemeigenes Bild zu kompilieren. In diesem Fall können Sie das System.Runtime.BypassNGenAttribute Attribut verwenden, um zu verhindern, dass NGen.exe ein systemeigenes Bild für eine bestimmte Methode generieren. Das Attribut muss einzeln auf jede Methode angewendet werden, deren Code sie nicht in das systemeigene Bild aufnehmen möchten. NGen.exe erkennt das Attribut und generiert keinen Code im systemeigenen Bild für die entsprechende Methode.

Beachten Sie jedoch, dass es BypassNGenAttribute sich nicht um einen Typ in der .NET Framework-Klassenbibliothek handelt. Um das Attribut in Ihrem Code zu verwenden, müssen Sie es zuerst wie folgt definieren:

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

Anschließend können Sie das Attribut pro Methode anwenden. Im folgenden Beispiel wird der native Image-Generator angewiesen, kein systemeigenes Image für die ExampleClass.ToJITCompile Methode zu generieren.

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

Der folgende Befehl generiert ein systemeigenes Image für ClientApp.exe, das sich im aktuellen Verzeichnis befindet, und installiert das Image im nativen Imagecache. Wenn eine Konfigurationsdatei für die Assembly vorhanden ist, verwendet Ngen.exe sie. Darüber hinaus werden systemeigene Bilder für alle .dll Dateien generiert, auf die ClientApp.exe verwiesen wird.

ngen install ClientApp.exe

Ein mit Ngen.exe installiertes Image wird auch als Stamm bezeichnet. Ein Stamm kann eine Anwendung oder eine freigegebene Komponente sein.

Der folgende Befehl generiert ein systemeigenes Bild für MyAssembly.exe den angegebenen Pfad.

ngen install c:\myfiles\MyAssembly.exe

Beim Suchen von Assemblys und deren Abhängigkeiten verwendet Ngen.exe dieselbe Probinglogik, die von der Common Language Runtime verwendet wird. Standardmäßig wird das Verzeichnis, das enthält ClientApp.exe , als Anwendungsbasisverzeichnis verwendet, und alle Assembly-Probings beginnen in diesem Verzeichnis. Sie können dieses Verhalten überschreiben, indem Sie die /AppBase Option verwenden.

Hinweis

Dies ist eine Änderung von Ngen.exe Verhalten in den .NET Framework-Versionen 1.0 und 1.1, wobei die Anwendungsbasis auf das aktuelle Verzeichnis festgelegt ist.

Eine Assembly kann eine Abhängigkeit ohne Verweis haben, z. B. wenn sie eine .dll Datei mithilfe der Assembly.Load Methode lädt. Sie können ein systemeigenes Image für eine solche .dll Datei erstellen, indem Sie Konfigurationsinformationen für die Anwendungsassembly mit der /ExeConfig Option verwenden. Der folgende Befehl generiert ein systemeigenes Image für MyLib.dll die Verwendung der Konfigurationsinformationen aus MyApp.exe.

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

Assemblys, die auf diese Weise installiert sind, werden nicht entfernt, wenn die Anwendung entfernt wird.

Verwenden Sie zum Deinstallieren einer Abhängigkeit die gleichen Befehlszeilenoptionen, die zum Installieren verwendet wurden. Mit dem folgenden Befehl wird das MyLib.dll vorherige Beispiel deinstalliert.

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

Verwenden Sie den Anzeigenamen der Assembly, um ein systemeigenes Image für eine Assembly im globalen Assemblycache zu erstellen. Beispiel:

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

NGen.exe generiert einen separaten Satz von Images für jedes Szenario, das Sie installieren. Die folgenden Befehle installieren z. B. einen vollständigen Satz systemeigener Images für den normalen Betrieb, einen weiteren vollständigen Satz für das Debuggen und ein Drittel für Profilerstellung:

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

Anzeigen des nativen Bildcaches

Sobald systemeigene Images im Cache installiert sind, können sie mit Ngen.exeangezeigt werden. Mit dem folgenden Befehl werden alle systemeigenen Bilder im nativen Bildcache angezeigt.

ngen display

Die display Aktion listet zuerst alle Stammassemblys auf, gefolgt von einer Liste aller systemeigenen Images auf dem Computer.

Verwenden Sie den einfachen Namen einer Assembly, um Informationen nur für diese Assembly anzuzeigen. Der folgende Befehl zeigt alle systemeigenen Bilder im nativen Bildcache an, die mit dem Teilnamen MyAssembly, ihren Abhängigkeiten und allen Wurzeln übereinstimmen, die eine Abhängigkeit haben MyAssembly:

ngen display MyAssembly

Das Wissen, welche Wurzeln von einer freigegebenen Komponentenassembly abhängen, ist nützlich, um die Auswirkungen einer update Aktion nach dem Upgrade der freigegebenen Komponente zu ermitteln.

Wenn Sie die Dateierweiterung einer Assembly angeben, müssen Sie entweder den Pfad angeben oder Ngen.exe aus dem Verzeichnis ausführen, das die Assembly enthält:

ngen display c:\myApps\MyAssembly.exe

Mit dem folgenden Befehl werden alle systemeigenen Bilder im nativen Bildcache mit dem Namen MyAssembly und der Version 1.0.0.0 angezeigt.

ngen display "myAssembly, version=1.0.0.0"

Aktualisieren von Bildern

Bilder werden in der Regel aktualisiert, nachdem eine freigegebene Komponente aktualisiert wurde. Wenn Sie alle systemeigenen Bilder aktualisieren möchten, die geändert wurden oder deren Abhängigkeiten geändert wurden, verwenden Sie die update Aktion ohne Argumente.

ngen update

Das Aktualisieren aller Bilder kann ein langer Prozess sein. Sie können die Updates für die Ausführung durch den systemeigenen Imagedienst in die Warteschlange stellen, indem Sie die /queue Option verwenden. Weitere Informationen zu den /queue Optionen und Installationsprioritäten finden Sie unter Native Image Service.

ngen update /queue

Deinstallieren von Bildern

Ngen.exe verwaltet eine Liste von Abhängigkeiten, sodass freigegebene Komponenten nur entfernt werden, wenn alle Assemblys, die von ihnen abhängig sind, entfernt wurden. Darüber hinaus wird eine freigegebene Komponente nicht entfernt, wenn sie als Stamm installiert wurde.

Mit dem folgenden Befehl werden alle Szenarien für den Stamm ClientApp.exedeinstalliert:

ngen uninstall ClientApp

Die uninstall Aktion kann verwendet werden, um bestimmte Szenarien zu entfernen. Der folgende Befehl deinstalliert alle Debugszenarien für ClientApp.exe:

ngen uninstall ClientApp /debug

Hinweis

Deinstallationsszenarien /debug deinstallieren kein Szenario, das beide /profile und /debug.

Mit dem folgenden Befehl werden alle Szenarien für eine bestimmte Version von ClientApp.exe:

ngen uninstall "ClientApp, Version=1.0.0.0"

Die folgenden Befehle deinstallieren alle Szenarien für "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL", oder nur das Debugszenario für diese 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

Wie bei der Aktion erfordert das install Bereitstellen einer Erweiterung entweder das Ausführen von Ngen.exe aus dem Verzeichnis, das die Assembly enthält, oder das Angeben eines vollständigen Pfads.

Beispiele für den systemeigenen Imagedienst finden Sie unter Native Image Service.

Systemeigene Bildaufgabe

Die systemeigene Imageaufgabe ist eine Windows-Aufgabe, die systemeigene Images generiert und verwaltet. Die systemeigene Bildaufgabe generiert und gibt systemeigene Bilder automatisch für unterstützte Szenarien zurück. Außerdem können Installationsprogramme Ngen.exe (Native Image Generator) verwenden, um systemeigene Images zu einem verzögerten Zeitpunkt zu erstellen und zu aktualisieren.

Die systemeigene Imageaufgabe wird einmal für jede CPU-Architektur registriert, die auf einem Computer unterstützt wird, um die Kompilierung für Anwendungen zu ermöglichen, die auf jede Architektur abzielen:

Taskname	32-Bit-Computer	64-Bit-Computer
NET Framework NGEN v4.0.30319	Yes	Yes
NET Framework NGEN v4.0.30319 64	Nein	Yes

Die systemeigene Imageaufgabe ist in .NET Framework 4.5 und höheren Versionen verfügbar, wenn sie unter Windows 8 oder höher ausgeführt werden. In früheren Versionen von Windows verwendet .NET Framework den nativen Imagedienst.

Aufgabenlebensdauer

Im Allgemeinen startet der Windows-Aufgabenplaner die systemeigene Imageaufgabe jede Nacht, wenn sich der Computer im Leerlauf befindet. Die Aufgabe überprüft alle verzögerten Arbeiten, die von Anwendungsinstallationsprogrammen in die Warteschlange gestellt werden, alle verzögerten systemeigenen Imageaktualisierungsanforderungen und alle automatischen Bilderstellungsanforderungen. Die Aufgabe schließt ausstehende Arbeitsaufgaben ab und wird dann heruntergefahren. Wenn der Computer während der Ausführung der Aufgabe nicht mehr im Leerlauf ist, wird die Aufgabe beendet.

Sie können die systemeigene Bildaufgabe auch manuell über die Task Scheduler-Benutzeroberfläche oder über manuelle Aufrufe an NGen.exestarten. Wenn die Aufgabe über eine dieser Methoden gestartet wird, wird sie weiterhin ausgeführt, wenn der Computer nicht mehr im Leerlauf ist. Bilder, die manuell mithilfe von NGen.exe erstellt werden, werden priorisiert, um ein vorhersagbares Verhalten für Anwendungsinstallationsprogramme zu ermöglichen.

Systemeigener Imagedienst

Der systemeigene Imagedienst ist ein Windows-Dienst, der systemeigene Images generiert und verwaltet. Mit dem systemeigenen Imagedienst kann der Entwickler die Installation und Aktualisierung systemeigener Images auf Zeiträume zurückstellen, in denen sich der Computer im Leerlauf befindet.

Normalerweise wird der systemeigene Imagedienst vom Installationsprogramm (Installationsprogramm) für eine Anwendung oder ein Update initiiert. Für Priorität 3-Aktionen wird der Dienst während der Leerlaufzeit auf dem Computer ausgeführt. Der Dienst speichert seinen Zustand und kann bei Bedarf mehrere Neustarts fortsetzen. Mehrere Bildkompilierungen können in die Warteschlange gestellt werden.

Der Dienst interagiert auch mit dem manuellen Ngen.exe Befehl. Manuelle Befehle haben Vorrang vor Hintergrundaktivitäten.

Hinweis

Unter Windows Vista lautet der für den systemeigenen Imagedienst angezeigte Name "Microsoft.NET Framework NGEN v2.0.50727_X86" oder "Microsoft.NET Framework NGEN v2.0.50727_X64". In allen früheren Versionen von Microsoft Windows lautet der Name ".NET Runtime Optimization Service v2.0.50727_X86" oder ".NET Runtime Optimization Service v2.0.50727_X64".

Starten verzögerter Vorgänge

Bevor Sie eine Installation oder ein Upgrade starten, wird das Anhalten des Diensts empfohlen. Dadurch wird sichergestellt, dass der Dienst nicht ausgeführt wird, während das Installationsprogramm Dateien kopiert oder Assemblys im globalen Assemblycache speichert. Die folgende Ngen.exe Befehlszeile hält den Dienst an:

ngen queue pause

Wenn alle verzögerten Vorgänge in die Warteschlange gestellt wurden, kann der Dienst mit dem folgenden Befehl fortgesetzt werden:

ngen queue continue

Verwenden Sie zum Verzögern der systemeigenen Imagegenerierung bei der Installation einer neuen Anwendung oder beim Aktualisieren einer freigegebenen Komponente die /queue Option mit den install Oder update Aktionen. Die folgenden Ngen.exe Befehlszeilen installieren ein systemeigenes Image für eine freigegebene Komponente und führen ein Update aller Wurzeln durch, die möglicherweise betroffen sind:

ngen install MyComponent /queue
ngen update /queue

Die update Aktion generiert alle systemeigenen Bilder, die ungültig wurden, nicht nur diejenigen, die verwendet werden MyComponent.

Wenn Ihre Anwendung aus vielen Wurzeln besteht, können Sie die Priorität der verzögerten Aktionen steuern. Mit den folgenden Befehlen wird die Installation von drei Wurzeln in die Warteschlange gestellt. Assembly1 wird zuerst installiert, ohne auf leerlaufzeit zu warten. Assembly2 wird auch installiert, ohne auf Leerlaufzeit zu warten, aber nachdem alle Prioritätsaktionen 1 abgeschlossen wurden. Assembly3 wird installiert, wenn der Dienst erkennt, dass der Computer im Leerlauf ist.

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

Sie können erzwingen, dass aktionen in der Warteschlange synchron ausgeführt werden, indem Sie die executeQueuedItems Aktion verwenden. Wenn Sie die optionale Priorität angeben, wirkt sich diese Aktion nur auf die Aktionen in der Warteschlange aus, die gleich oder niedriger sind. Die Standardpriorität ist 3, sodass der folgende Ngen.exe Befehl alle in die Warteschlange eingereihten Aktionen sofort verarbeitet und erst zurückgegeben wird, wenn sie fertig sind:

ngen executeQueuedItems

Synchrone Befehle werden von Ngen.exe ausgeführt und verwenden nicht den systemeigenen Imagedienst. Sie können Aktionen mit Ngen.exe ausführen, während der systemeigene Imagedienst ausgeführt wird.

Dienst heruntergefahren

Nach dem Initiieren durch die Ausführung eines Ngen.exe Befehls, der die /queue Option enthält, wird der Dienst im Hintergrund ausgeführt, bis alle Aktionen abgeschlossen wurden. Der Dienst speichert seinen Zustand, damit er bei Bedarf über mehrere Neustarts fortgesetzt werden kann. Wenn der Dienst erkennt, dass keine weiteren Aktionen in die Warteschlange gestellt werden, setzt er seinen Status zurück, sodass er nicht neu gestartet wird, wenn der Computer das nächste Mal gestartet wird, und dann wird er heruntergefahren.

Dienstinteraktion mit Clients

In .NET Framework, Version 2.0, ist die einzige Interaktion mit dem systemeigenen Imagedienst über das Befehlszeilentool Ngen.exe. Verwenden Sie das Befehlszeilentool in Installationsskripts, um Aktionen für den systemeigenen Imagedienst in die Warteschlange zu stellen und mit dem Dienst zu interagieren.

Siehe auch

• Werkzeuge
• Verwalteter Ausführungsprozess
• Wie die Laufzeit Assemblys findet
• Befehlszeilenshells für Entwickler