Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält ergänzende Hinweise zur Referenzdokumentation für diese API.
Das AssemblyLoadContext stellt einen Ladekontext dar. Konzeptionell erstellt ein Ladekontext einen Bereich zum Laden, Auflösen und potenziell Entladen einer Gruppe von Assemblys.
Das AssemblyLoadContext existiert in erster Linie, um die Isolierung beim Laden von Assemblys zu gewährleisten. Sie ermöglicht es mehreren Versionen derselben Assembly, innerhalb eines einzelnen Prozesses zu laden. Es ersetzt die Isolationsmechanismen, die von mehreren AppDomain Instanzen in .NET Framework bereitgestellt werden.
Hinweis
- AssemblyLoadContext stellt keine Sicherheitsfeatures bereit. Der gesamte Code verfügt über vollständige Berechtigungen für den Prozess.
- In .NET Core 2.0 - 2.2 ist nur AssemblyLoadContext eine abstrakte Klasse. Implementieren Sie die AssemblyLoadContext.Load(AssemblyName) Methode, um eine konkrete Klasse in diesen Versionen zu erstellen.
Verwendung in der Runtime
Die Laufzeit implementiert zwei Assemblyladekontexte:
- AssemblyLoadContext.Default stellt den Standardkontext der Laufzeit dar, der für die Hauptassembly der Anwendung und deren statische Abhängigkeiten verwendet wird.
- Die Methode Assembly.LoadFile(String) isoliert die geladenen Assemblies, indem sie das einfachste AssemblyLoadContext instanziiert. Sie verfügt über ein einfaches Isolationsschema, das jede Assembly in ihrer eigenen AssemblyLoadContext ohne Auflösung von Abhängigkeiten lädt.
Anwendungsnutzung
Eine Anwendung kann ihr eigenes AssemblyLoadContext erstellen, um maßgeschneiderte Lösungen für erweiterte Szenarien zu entwickeln. Die Anpassung konzentriert sich auf die Definition von Abhängigkeitsauflösungsmechanismen.
Der AssemblyLoadContext bietet zwei Erweiterungspunkte zur Implementierung der verwalteten Assembly-Auflösung:
- Die AssemblyLoadContext.Load(AssemblyName) Methode bietet die erste Möglichkeit, die AssemblyLoadContext Assembly aufzulösen, zu laden und zurückzugeben. Wenn die Methode AssemblyLoadContext.Load(AssemblyName)
null
zurückgibt, versucht das Ladeprogramm, die Assembly in die AssemblyLoadContext.Default zu laden. - Wenn die AssemblyLoadContext.Default Assembly nicht aufgelöst werden kann, erhält das Original AssemblyLoadContext eine zweite Chance, die Assembly aufzulösen. Die Runtime löst das Ereignis Resolving aus.
Zusätzlich bietet die virtuelle Methode AssemblyLoadContext.LoadUnmanagedDll(String) die Möglichkeit, die Standardauflösung für nicht verwaltete Assemblys anzupassen. Die Standardimplementierung gibt zurück null
, wodurch die Laufzeitsuche die Standardsuchrichtlinie verwendet. Die Standardmäßige Suchrichtlinie ist für die meisten Szenarien ausreichend.
Technische Herausforderungen
Es ist nicht möglich, mehrere Versionen der Laufzeit in einem einzigen Prozess zu laden.
Vorsicht
Das Laden mehrerer Kopien oder verschiedener Versionen von Frameworkassemblys kann zu unerwartetem und schwer zu diagnostizierenden Verhalten führen.
Tipp
Verwenden Sie Prozessgrenzen mit Remoting oder Interprocess-Kommunikation, um dieses Isolationsproblem zu lösen.
Der Zeitpunkt des Ladens einer Assembly kann das Testen und Debuggen erschweren. Assemblys werden normalerweise geladen, ohne dass ihre Abhängigkeiten sofort aufgelöst werden. Die Abhängigkeiten werden geladen, wenn sie benötigt werden:
- Wenn Code in eine abhängige Assembly verzweigt.
- Wenn Code Ressourcen lädt.
- Wenn Code Assemblys explizit lädt.
Die Implementierung von AssemblyLoadContext.Load(AssemblyName) kann neue Abhängigkeiten hinzufügen, die möglicherweise isoliert werden müssen, damit verschiedene Versionen nebeneinander existieren können. Die natürlichste Implementierung würde diese Abhängigkeiten im Standardkontext platzieren. Das sorgfältige Design kann die neuen Abhängigkeiten isolieren.
Dieselbe Assembly wird mehrmals in verschiedene Kontexte geladen.
- Dies kann zu verwirrenden Fehlermeldungen führen, z. B. "Das Objekt vom Typ 'Sample.Plugin' kann nicht in den Typ 'Sample.Plugin' konvertiert werden."
- Das Marshalling über Isolationsgrenzen hinweg ist nicht trivial. Eine typische Lösung besteht darin, eine in einer Assembly definierte Schnittstelle zu verwenden, die nur in den Standardladekontext geladen wird.