So sucht Common Language Runtime nach Assemblys
Aktualisiert: November 2007
Um Ihre .NET Framework-Anwendung erfolgreich bereitstellen zu können, müssen Sie mit dem Verfahren vertraut sein, mit dem die Common Language Runtime die Assemblys sucht und bindet, aus denen Ihre Anwendung zusammengesetzt ist. Standardmäßig versucht die Common Language Runtime, die genaue Version einer Assembly einzubinden, mit der die Anwendung erstellt wurde. Dieses Standardverhalten kann durch Einstellungen in der Konfigurationsdatei überschrieben werden.
Die Common Language Runtime führt mehrere Schritte aus, um eine Assembly zu finden und einen Verweis auf eine Assembly aufzulösen. Jeder Schritt wird in den folgenden Abschnitten erläutert. Der Begriff "Überprüfung" wird häufig verwendet, um zu beschreiben, wie die Common Language Runtime nach Assemblys sucht. Er verweist auf einige Heuristiken, mit denen die Assembly auf Basis ihres Namens und ihrer Kultur gesucht wird.
.gif "Hinweis") Hinweis: |
|---|
Bindungsinformationen können in der Protokolldatei mit dem Assembly Binding Log Viewer-Tool (Fuslogvw.exe) angezeigt werden, das in Windows Software Development Kit (SDK) enthalten ist. |
Initiieren der Bindung
Das Auffinden einer und Binden an eine Assembly beginnt mit dem Versuch der Common Language Runtime, einen Verweis auf eine andere Assembly aufzulösen. Dieser Verweis kann statisch oder dynamisch sein. Der Compiler zeichnet statische Verweise in den Metadaten des Assemblymanifests während der Erstellungszeit auf. Dynamische Verweise werden dynamisch erstellt und resultieren aus dem Aufruf verschiedener Methoden, z. B. System.Reflection.Assembly.Load.
Der bevorzugte Weg zum Verweisen auf eine Assembly ist die Verwendung eines vollständigen Verweises mit Assemblynamen, -version, -kultur und Token des öffentlichen Schlüssels (falls vorhanden). Diese Informationen werden von der Common Language Runtime bei der Suche nach der Assembly verwendet. Die dabei ausgeführten Schritte werden in diesem Abschnitt weiter unten beschrieben. Der verwendete Auflösungsprozess ist immer gleich, unabhängig davon, ob der Verweis sich auf eine statische oder dynamische Assembly bezieht.
Sie können auch dynamisch auf eine Assembly verweisen, indem Sie die Methode nur unter Angabe partieller Informationen zur Assembly, z. B. des Assemblynamens, aufrufen. In diesem Fall wird lediglich das Anwendungsverzeichnis nach der Assembly durchsucht; es erfolgen keine weiteren Überprüfungen. Einen partiellen Verweis können Sie mit allen verschiedenen Methoden, die es zum Laden von Assemblys gibt, erstellen, etwa mit System.Reflection.Assembly.Load oder System.AppDomain.Load.
Mit einer Methode wie der System.Reflection.Assembly.Load-Methode können Sie schließlich auch dynamische Verweise erstellen und nur partielle Informationen angeben. Dann können Sie den Verweis mit dem <qualifyAssembly>-Element in der Anwendungskonfigurationsdatei kennzeichnen. Mit diesem Element können Sie die vollständigen Verweisinformationen (Name, Version, Kultur und ggf. das Token des öffentlichen Schlüssels) in der Anwendungskonfigurationsdatei anstelle im Code bereitstellen. Dieses Verfahren sollten Sie anwenden, wenn Sie einen Verweis auf eine Assembly außerhalb des Anwendungsverzeichnisses voll kennzeichnen oder auf eine Assembly im globalen Assemblycache verweisen möchten, aber gleichzeitig aus praktischen Gründen den vollständigen Verweis in der Konfigurationsdatei statt im Code angeben möchten.
| Hinweis: |
|---|
Diesen Typ des partiellen Verweises sollten Sie nicht bei Assemblys verwenden, die für mehrere Anwendungen freigegeben sind. Da Konfigurationseinstellungen nach Anwendung und nicht nach Assembly erfolgen, müssten bei einer freigegebenen Assembly mit diesem Typ des partiellen Verweises jede Anwendung, die diese freigegebene Assembly verwendet, in der Konfigurationsdatei die kennzeichnenden Informationen enthalten sein. |
Folgende Schritte werden ausgeführt, um einen Verweis auf eine Assembly aufzulösen:
Bestimmen der korrekten Assemblyversion durch Überprüfung anwendbarer Konfigurationsdateien, einschließlich der Konfigurationsdatei der Anwendung, der Herausgeberrichtliniendatei und der Computerkonfigurationsdatei. Wenn die Konfigurationsdatei auf einem Remotecomputer gespeichert ist, muss zuerst die Konfigurationsdatei der Anwendung gesucht und heruntergeladen werden.
Überprüfen, ob der Assemblyname bereits zuvor gebunden wurde. Ist dies der Fall, wird die zuvor geladene Assembly verwendet. Wenn eine vorherige Anforderung zum Laden der Assembly nicht ausgeführt werden konnte, führt die Anforderung sofort zu einem Fehler, ohne dass versucht wird, die Assembly zu laden.
Hinweis:Das Caching von Assemblybindungsfehlern ist neu in .NET Framework, Version 2.0.
Durchsuchen des globalen Assemblycaches. Wird die Assembly dort gefunden, wird sie von der Common Language Runtime verwendet.
Suchen der Assembly, wobei folgendermaßen vorgegangen wird:
Wenn die Konfigurations- und Herausgeberrichtlinien keine Auswirkungen auf den ursprünglichen Verweis haben und die Anforderung zur Bindung mithilfe der Assembly.LoadFrom-Methode erstellt wurde, wird nach Hinweisen auf den Speicherort gesucht.
Wenn eine CodeBase in den Konfigurationsdateien gefunden wurde, wird nur diese Position überprüft. Wenn die Überprüfung fehlschlägt, wird durch die Common Language Runtime festgelegt, dass die Anforderung zur Bindung fehlgeschlagen ist und keine weitere Überprüfung erfolgt.
Überprüfen der Assembly mithilfe von Heuristiken, die im Abschnitt Sondieren beschrieben werden. Wurde die Assembly nach der Überprüfung nicht gefunden, fordert die Common Language Runtime Windows Installer auf, die Assembly zur Verfügung zu stellen. Dabei handelt es sich um eine Installation bei Bedarf.
Hinweis:Es findet weder eine Versionsüberprüfung von Assemblys mit starkem Namen statt, noch überprüft die Common Language Runtime den globalen Assemblycache nach Assemblys ohne starken Namen.
Siehe auch
Konzepte
Bereitstellungsszenarien für .NET Framework-Anwendungen
Schritt 1: Untersuchen der Konfigurationsdateien
Schritt 2: Suchen nach Assemblys, auf die zuvor verwiesen wurde
Schritt 3: Durchsuchen des globalen Assemblycaches
Schritt 4: Suchen der Assembly mit CodeBases oder durch Sondierung