Freigeben über

So sucht Common Language Runtime nach Assemblys

Hinweis

Dieser Artikel ist spezifisch für .NET Framework. Sie gilt nicht für neuere Implementierungen von .NET, einschließlich .NET 6 und höherer Versionen.

Um Ihre .NET Framework-Anwendung erfolgreich bereitzustellen, müssen Sie verstehen, wie die Common Language Runtime die Assemblys sucht und bindet, aus denen Ihre Anwendung besteht. Standardmäßig versucht die Laufzeit, eine Bindung mit der genauen Version einer Assembly zu erstellen, mit der die Anwendung erstellt wurde. Dieses Standardverhalten kann durch Konfigurationsdateieinstellungen außer Kraft gesetzt werden.

Die Common Language Runtime führt eine Reihe von Schritten aus, wenn Sie versuchen, eine Assembly zu finden und einen Assemblyverweis 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 bezieht sich auf die Heuristiken, mit denen die Assembly auf Basis ihres Namens und ihrer Kultur gesucht wird.

Hinweis

Sie können Bindungsinformationen in der Protokolldatei mithilfe der Assemblybindungsprotokollanzeige (Fuslogvw.exe) anzeigen, die im Windows SDK enthalten ist.

Initiieren der Bindung

Der Prozess der Suche und Bindung an eine Assembly beginnt, wenn die Laufzeit versucht, 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 beim Erstellen auf. Dynamische Verweise werden spontan erstellt, indem verschiedene Methoden aufgerufen werden, wie zum Beispiel Assembly.Load.

Die bevorzugte Methode zum Verweisen auf eine Assembly besteht darin, einen vollständigen Verweis zu verwenden, einschließlich des Assemblynamens, der Version, der Kultur und des öffentlichen Schlüsseltokens (sofern vorhanden). Die Laufzeit verwendet diese Informationen, um die Assembly zu finden, indem sie die im weiteren Verlauf dieses Abschnitts beschriebenen Schritte ausführt. Die Laufzeit verwendet den gleichen Auflösungsprozess, unabhängig davon, ob der Verweis für eine statische oder dynamische Assembly ist.

Sie können auch einen dynamischen Verweis auf eine Assembly erstellen, indem Sie der aufrufenden Methode nur teilweise Informationen über die Assembly angeben, z. B. nur den Assemblynamen angeben. In diesem Fall wird lediglich das Anwendungsverzeichnis nach der Assembly durchsucht; es erfolgen keine weiteren Überprüfungen. Sie erstellen einen Teilverweis mithilfe einer der verschiedenen Methoden zum Laden von Assemblys wie Assembly.Load oder AppDomain.Load.

Schließlich können Sie einen dynamischen Verweis mithilfe einer Methode wie Assembly.Load und zum Beispiel nur teilweise Informationen bereitstellen. Anschließend qualifizieren Sie den Verweis mithilfe des <„qualifyAssembly>“-Elements in der Anwendungskonfigurationsdatei. Mit diesem Element können Sie die vollständigen Referenzinformationen (Name, Version, Kultur und ggf. das Öffentliche Schlüsseltoken) in Ihrer Anwendungskonfigurationsdatei anstelle in Ihrem Code bereitstellen. Sie würden diese Technik verwenden, wenn Sie einen Verweis auf eine Assembly außerhalb des Anwendungsverzeichnisses vollständig qualifizieren möchten oder wenn Sie auf eine Assembly im globalen Assemblycache verweisen möchten, aber Sie wollten den vollständigen Verweis in der Konfigurationsdatei anstelle des Codes angeben.

Hinweis

Dieser Teilverweistyp sollte nicht für Assemblys verwendet werden, die von mehreren Anwendungen gemeinsam genutzt werden. Da Konfigurationseinstellungen pro Anwendung und nicht pro Assembly angewendet werden, muss eine freigegebene Assembly, die diesen Teilverweistyp verwendet, dafür sorgen, dass jede Anwendung, welche die freigegebene Assembly nutzt, die qualifizierenden Informationen in ihrer Konfigurationsdatei enthält.

Die Laufzeit verwendet die folgenden Schritte, um einen Assemblyverweis aufzulösen:

  1. Bestimmt die richtige Assemblyversion , indem die entsprechenden Konfigurationsdateien untersucht werden, einschließlich der Anwendungskonfigurationsdatei, der Herausgeberrichtliniendatei und der Computerkonfigurationsdatei. Wenn sich die Konfigurationsdatei auf einem Remotecomputer befindet, muss die Laufzeit zuerst die Anwendungskonfigurationsdatei suchen und herunterladen.

  2. Überprüft, ob der Assemblyname vorher gebunden wurde , und verwendet ggf. die zuvor geladene Assembly. Wenn eine vorherige Anforderung zum Laden der Assembly fehlgeschlagen ist, ist die Anforderung sofort fehlgeschlagen, ohne zu versuchen, die Assembly zu laden.

    Hinweis

    Das Zwischenspeichern von Assemblybindungsfehlern ist neu in .NET Framework, Version 2.0.

  3. Überprüft den globalen Assemblycache. Wenn die Assembly dort gefunden wird, verwendet die Laufzeit diese Assembly.

  4. Suchen der Assembly , wobei folgendermaßen vorgegangen wird:

    1. Wenn sich die Konfigurations- und Herausgeberrichtlinie nicht auf den ursprünglichen Verweis auswirken und die Bindungsanforderung mithilfe der Assembly.LoadFrom Methode erstellt wurde, sucht die Laufzeit nach Standorthinweisen.

    2. Wenn eine Codebasis in den Konfigurationsdateien gefunden wird, überprüft die Laufzeit nur diesen Speicherort. Wenn dieser Prüfpunkt fehlschlägt, bestimmt die Laufzeit, dass die Bindungsanforderung fehlgeschlagen ist und keine andere Überprüfung auftritt.

    3. Überprüfen der Assembly mithilfe von Heuristiken, die im Abschnitt Überprüfungbeschrieben sind. Wenn die Assembly nach dem Probing nicht gefunden wird, fordert die Laufzeit das Windows Installer an, die Assembly bereitzustellen. Dies dient als Install-on-Demand-Feature.

      Hinweis

      Es gibt keine Versionsprüfung für Assemblys ohne starke Namen, noch wird zur Laufzeit im globalen Assemblycache nach Assemblys ohne starke Namen gesucht.

Schritt 1: Untersuchen der Konfigurationsdateien

Das Verhalten der Assemblybindung kann auf unterschiedlichen Ebenen basierend auf drei XML-Dateien konfiguriert werden:

  • Anwendungskonfigurationsdatei.

  • Herausgeberrichtliniendatei

  • Computerkonfigurationsdatei.

Diese Dateien folgen derselben Syntax und stellen Informationen wie Bindungsumleitungen, den Speicherort von Code und Bindungsmodi für bestimmte Assemblys bereit. Jede Konfigurationsdatei kann ein <assemblyBinding-Element> enthalten, das den Bindungsprozess umleitet. Die untergeordneten Elemente des <assemblyBinding>-Elements enthalten das <dependentAssembly>-Element. Die untergeordneten Elemente des <dependentAssembly>-Elements enthalten das <assemblyIdentity>-Element, das <bindingRedirect>-Element und das <codeBase>-Element.

Hinweis

Konfigurationsinformationen finden Sie in den drei Konfigurationsdateien; nicht alle Elemente sind in allen Konfigurationsdateien gültig. Beispielsweise können bindungsmodus- und private Pfadinformationen nur in der Anwendungskonfigurationsdatei enthalten sein. Eine vollständige Liste der Informationen, die in jeder Datei enthalten sind, finden Sie unter Konfigurieren von Apps mithilfe von Konfigurationsdateien.

Anwendungskonfigurationsdatei

Zunächst überprüft die Common Language Runtime die Anwendungskonfigurationsdatei auf Informationen, die die versionsinformationen überschreiben, die im Manifest der aufrufenden Assembly gespeichert sind. Die Anwendungskonfigurationsdatei kann mit einer Anwendung bereitgestellt werden, ist jedoch nicht für die Anwendungsausführung erforderlich. Normalerweise ist der Abruf dieser Datei fast sofort, aber in Situationen, in denen sich die Anwendungsbasis auf einem Remotecomputer befindet, z. B. in einem webbasierten Szenario, muss die Konfigurationsdatei heruntergeladen werden.

Bei ausführbaren Clientdateien befindet sich die Anwendungskonfigurationsdatei im selben Verzeichnis wie die ausführbare Datei der Anwendung und hat denselben Basisnamen wie die ausführbare Datei mit einer .config Erweiterung. Die Konfigurationsdatei für C:\Program Files\Myapp\Myapp.exe ist z. B. C:\Program Files\Myapp\Myapp.exe.config. In einem browserbasierten Szenario muss die HTML-Datei das <Linkelement> verwenden, um explizit auf die Konfigurationsdatei zu verweisen.

Der folgende Code enthält ein einfaches Beispiel für eine Anwendungskonfigurationsdatei. In diesem Beispiel wird der TextWriterTraceListener-Auflistung eine Listeners hinzugefügt, um die Aufzeichnung von Debuginformationen in eine Datei zu aktivieren.

<configuration>
   <system.diagnostics>
      <trace useGlobalLock="false" autoflush="true" indentsize="0">
         <listeners>
            <add name="myListener" type="System.Diagnostics.TextWriterTraceListener, system version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="c:\myListener.log" />
         </listeners>
      </trace>
   </system.diagnostics>
</configuration>

Herausgeberrichtliniendatei

Im zweiten Schritt überprüft die Common Language Runtime die Herausgeberrichtliniendatei, sofern eine solche vorhanden ist. Herausgeberrichtliniendateien werden von einem Komponentenherausgeber als Fix oder Update an eine freigegebene Komponente verteilt. Diese Dateien enthalten Vom Herausgeber der freigegebenen Komponente ausgegebene Kompatibilitätsinformationen, die einen Assemblyverweis auf eine neue Version leiten. Im Gegensatz zu Anwendungs- und Computerkonfigurationsdateien sind Herausgeberrichtliniendateien in ihrer eigenen Assembly enthalten, die im globalen Assemblycache installiert werden muss.

Im Folgenden sehen Sie ein Beispiel für eine Publisher-Richtlinienkonfigurationsdatei:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

            <dependentAssembly>
                <assemblyIdentity name="asm6" publicKeyToken="c0305c36380ba429" />
                <bindingRedirect oldVersion="3.0.0.0" newVersion="2.0.0.0"/>
            </dependentAssembly>

        </assemblyBinding>
    </runtime>
</configuration>

Zum Erstellen einer Assembly können Sie das toolAl.exe (Assembly Linker) mit einem Befehl wie den folgenden verwenden:

Al.exe /link:asm6.exe.config /out:policy.3.0.asm6.dll /keyfile: compatkey.dat /v:3.0.0.0

compatkey.dat ist eine Schlüsseldatei mit starkem Namen. Mit diesem Befehl wird eine assembly mit starkem Namen erstellt, die Sie im globalen Assemblycache platzieren können.

Hinweis

Publisher-Richtlinie wirkt sich auf alle Anwendungen aus, die eine freigegebene Komponente verwenden.

Die Herausgeberrichtlinienkonfigurationsdatei setzt Versionsinformationen außer Kraft, die aus der Anwendung stammen (d. a. aus dem Assemblymanifest oder aus der Anwendungskonfigurationsdatei). Wenn in der Anwendungskonfigurationsdatei keine Anweisung vorhanden ist, um die im Assemblymanifest angegebene Version umzuleiten, überschreibt die Herausgeberrichtliniendatei die im Assemblymanifest angegebene Version. Wenn jedoch eine Umleitungsanweisung in der Anwendungskonfigurationsdatei vorhanden ist, überschreibt die Herausgeberrichtlinie diese Version und nicht die im Manifest angegebene.

Eine Herausgeberrichtliniendatei wird verwendet, wenn eine freigegebene Komponente aktualisiert wird und die neue Version der freigegebenen Komponente von allen Anwendungen übernommen werden soll, die diese Komponente verwenden. Die Einstellungen in der Herausgeberrichtliniendatei setzen Einstellungen in der Anwendungskonfigurationsdatei außer Kraft, es sei denn, die Anwendungskonfigurationsdatei erzwingt den abgesicherten Modus.

Abgesicherter Modus

Publisher-Richtliniendateien werden in der Regel explizit als Teil eines Service Packs oder Programmupdates installiert. Wenn Probleme mit der aktualisierten, gemeinsam genutzten Komponente auftreten, können Sie die Überschreibungen in der Richtliniendatei des Herausgebers mithilfe des abgesicherten Modus ignorieren. Der abgesicherte Modus wird durch das <publisherPolicy apply="yes|no"/-> Element bestimmt, das sich nur in der Anwendungskonfigurationsdatei befindet. Es gibt an, ob die Konfigurationsinformationen der Herausgeberrichtlinie aus dem Bindungsprozess entfernt werden müssen.

Der abgesicherte Modus kann für die gesamte Anwendung oder für ausgewählte Assemblys festgelegt werden. Das heißt, Sie können die Richtlinie für alle Assemblys deaktivieren, aus denen die Anwendung besteht, oder sie für einige Assemblys aktivieren, aber nicht für andere. Wenn Sie die Publisher-Richtlinie selektiv auf Assemblys anwenden möchten, aus denen eine Anwendung besteht, legen Sie <"publisherPolicy apply=no/"> fest, und geben Sie an, welche Assemblys mit dem <dependentAssembly-Element> betroffen sein sollen. Wenn Sie die Herausgeberrichtlinie auf alle Assemblys anwenden möchten, aus denen die Anwendung besteht, legen Sie <publisherPolicy apply=no> ohne abhängige Assemblyelemente fest. Weitere Informationen zur Konfiguration finden Sie unter Konfigurieren von Apps mithilfe von Konfigurationsdateien.

Computerkonfigurationsdatei

Drittens untersucht die Laufzeit die Computerkonfigurationsdatei. Diese Datei, die als Machine.configbezeichnet wird, befindet sich auf dem lokalen Computer im Unterverzeichnis "Config" des Stammverzeichnisses, in dem die Laufzeit installiert ist. Diese Datei kann von Administratoren verwendet werden, um Assemblybindungseinschränkungen anzugeben, die auf diesem Computer lokal sind. Die Einstellungen in der Computerkonfigurationsdatei haben Vorrang vor allen anderen Konfigurationseinstellungen; Dies bedeutet jedoch nicht, dass alle Konfigurationseinstellungen in dieser Datei abgelegt werden sollen. Die von der Administratorrichtliniendatei festgelegte Version ist endgültig und kann nicht außer Kraft gesetzt werden. Überschreibungen, die in der Datei "Machine.config" festgelegt sind, haben Auswirkungen auf alle Anwendungen. Weitere Informationen zu Konfigurationsdateien finden Sie unter Konfigurieren von Apps mithilfe von Konfigurationsdateien.

Schritt 2: Suchen nach Assemblys, auf die zuvor verwiesen wurde

Wenn die angeforderte Assembly auch in vorherigen Aufrufen angefordert wurde, verwendet die Common Language Runtime die bereits geladene Assembly. Dies kann Auswirkungen haben, wenn Assemblys benannt werden, die eine Anwendung bilden. Weitere Informationen zum Benennen von Assemblys finden Sie unter Assemblynamen.

Wenn eine vorherige Anforderung für die Assembly fehlgeschlagen ist, sind nachfolgende Anforderungen für die Assembly sofort fehlgeschlagen, ohne zu versuchen, die Assembly zu laden. Ab .NET Framework, Version 2.0, werden Assemblybindungsfehler zwischengespeichert, und die zwischengespeicherten Informationen werden verwendet, um zu bestimmen, ob versucht wird, die Assembly zu laden.

Hinweis

Wenn Sie auf das Verhalten der .NET Framework-Versionen 1.0 und 1.1 zurücksetzen möchten, bei dem keine Bindungsfehler zwischengespeichert wurden, schließen Sie das <disableCachingBindingFailures-Element> in die Konfigurationsdatei ein.

Schritt 3: Durchsuchen des globalen Assemblycache

Für Assemblys mit starkem Namen wird der Bindungsprozess durch die Überprüfung des globalen Assemblycache fortgesetzt. Der globale Assemblycache speichert Assemblys, die von mehreren Anwendungen auf einem Computer verwendet werden können. Alle Assemblys im globalen Assemblycache müssen einen starken Namen aufweisen.

Schritt 4: Suchen der Assembly mittels Codebasen oder Abtasten

Nachdem die richtige Assemblyversion anhand der Informationen im Verweis der aufrufenden Assembly und in den Konfigurationsdateien ermittelt wurde und nachdem sie im globalen Assemblycache (nur für assemblys mit starkem Namen) eingecheckt wurde, versucht die Common Language Runtime, die Assembly zu finden. Der Vorgang zum Auffinden einer Assembly umfasst die folgenden Schritte:

  1. Wenn ein <CodeBase-Element> in der Anwendungskonfigurationsdatei gefunden wird, überprüft die Laufzeit den angegebenen Speicherort. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly verwendet und es findet keine Überprüfung statt. Wird die Assembly dort nicht gefunden, schlägt die Bindungsanforderung fehl.

  2. Die Common Language Runtime sucht daraufhin nach der Assembly, auf die verwiesen wurde, und wendet dabei die Regeln an, die weiter unten im Abschnitt erläutert sind.

Hinweis

Wenn Sie über mehrere Versionen einer Assembly in einem Verzeichnis verfügen und auf eine bestimmte Version dieser Assembly verweisen möchten, müssen Sie das <CodeBase-Element> anstelle des privatePath Attributs des <Probingelements> verwenden. Wenn Sie das <Probingelement> verwenden, beendet die Laufzeitumgebung das Probing beim ersten Mal, wenn sie eine Assembly findet, die dem einfachen Assemblynamen entspricht, auf den verwiesen wird, unabhängig davon, ob sie korrekt ist oder nicht. Bei einer korrekten Übereinstimmung wird diese Assembly verwendet. Wenn es sich nicht um eine korrekte Übereinstimmung handelt, wird die Überprüfung beendet und die Bindung schlägt fehl.

Assemblysuche mit CodeBases

Codebasisinformationen können mithilfe eines <CodeBase-Elements> in einer Konfigurationsdatei bereitgestellt werden. Diese Codebasis wird immer überprüft, bevor die Laufzeit versucht, die Referenzassembly zu prüfen. Enthält eine Herausgeberrichtliniendatei, in der die Umleitung der endgültigen Version enthalten ist, auch ein <codeBase>-Element, wird dieses <codeBase>-Element verwendet. Wenn Ihre Anwendungskonfigurationsdatei beispielsweise ein <CodeBase-Element> angibt und eine Herausgeberrichtliniendatei, die die Anwendungsinformationen überschreibt, auch ein <CodeBase-Element angibt, wird das CodeBase-Element><in der Herausgeberrichtliniendatei verwendet.>

Wenn an dem durch das <codeBase-Element> angegebenen Speicherort keine Übereinstimmung gefunden wird, schlägt die Bindungsanforderung fehl, und es werden keine weiteren Schritte ausgeführt. Wenn die Laufzeit bestimmt, dass eine Assembly den Kriterien der aufrufenden Assembly entspricht, wird diese Assembly verwendet. Wenn die durch das angegebene <codeBase-Element> angegebene Datei geladen wird, überprüft die Laufzeit, ob der Name, die Version, die Kultur und der öffentliche Schlüssel mit dem Verweis der aufrufenden Assembly übereinstimmen.

Hinweis

Referenzierte Assemblys außerhalb des Stammverzeichnisses der Anwendung müssen starke Namen aufweisen und entweder im globalen Assemblycache installiert oder mithilfe des <CodeBase-Elements> angegeben werden.

Assemblysuche durch Überprüfung

Wenn in der Anwendungskonfigurationsdatei kein <CodeBase-Element> vorhanden ist, verwenden die Laufzeitsonden für die Assembly vier Kriterien:

  • Anwendungsbasis, bei der es sich um den Stammspeicherort handelt, an dem die Anwendung ausgeführt wird.

  • Kultur, die das Kulturattribut der Assembly darstellt, auf die verwiesen wird.

  • Name der Assembly, auf die verwiesen wird.

  • Das privatePath-Attribut des <probing>-Elements, bei dem es sich um die benutzerdefinierte Liste von Unterverzeichnissen unter dem Stammspeicherort handelt. Dieser Speicherort kann in der Anwendungskonfigurationsdatei und im verwalteten Code mithilfe der AppDomainSetup.PrivateBinPath Eigenschaft für eine Anwendungsdomäne angegeben werden. Wenn in verwaltetem Code angegeben, wird zuerst der verwaltete Code privatePath untersucht, gefolgt vom Pfad, der in der Anwendungskonfigurationsdatei angegeben ist.

Untersuchung der Anwendungsbasis und der Kulturverzeichnisse

Die Laufzeit beginnt immer mit der Probingung in der Basis der Anwendung, die entweder eine URL oder das Stammverzeichnis der Anwendung auf einem Computer sein kann. Wird die Assembly, auf die verwiesen wird, in der Anwendungsbasis nicht gefunden und stehen keine Informationen zur Kultur bereit, durchsucht die Common Language Runtime alle Unterverzeichnisse mit diesem Assemblynamen. Zu den überprüften Verzeichnissen gehören:

  • [Anwendungsbasis] / [Assembly-Name].dll

  • [Anwendungsbasis] / [Assemblyname] / [Assemblyname].dll

Wenn für die Assembly, auf die verwiesen wird, Informationen zur Kultur angegeben sind, werden nur die folgenden Verzeichnisse überprüft:

  • [Anwendungsbasis] / [Kultur] / [Assemblyname].dll

  • [Anwendungsbasis] / [Kultur] / [Assemblyname] / [Assemblyname].dll

Überprüfen mit dem privatePath-Attribut

Zusätzlich zu den Unterverzeichnissen der Kultur und den Unterverzeichnissen mit dem Namen der Assembly, auf die verwiesen wird, überprüft die Common Language Runtime auch Verzeichnisse, die mit dem privatePath-Attribut des <probing>-Elements angegeben werden. Die mit dem privatePath Attribut angegebenen Verzeichnisse müssen Unterverzeichnisse des Stammverzeichnisses der Anwendung sein. Die überprüften Verzeichnisse unterscheiden sich, je nachdem, ob Informationen zur Kultur in der Anforderung der Assembly enthalten sind, auf die verwiesen wird.

Die Common Language Runtime beendet die Überprüfung beim ersten Auffinden einer Assembly mit dem einfachen Assemblynamen, auf den verwiesen wird, ganz gleich, ob es sich um eine korrekte Übereinstimmung handelt oder nicht. Bei einer korrekten Übereinstimmung wird diese Assembly verwendet. Wenn es sich nicht um eine korrekte Übereinstimmung handelt, wird die Überprüfung beendet und die Bindung schlägt fehl.

Wenn Kultur enthalten ist, werden die folgenden Verzeichnisse untersucht:

  • [Anwendungsbasis] / [bin-Pfad] / [Kultur] / [Assemblyname].dll

  • [Anwendungsbasis] / [bin-Pfad] / [Kultur] / [Assemblyname] / [Assemblyname].dll

Wenn keine Kulturinformationen enthalten sind, werden die folgenden Verzeichnisse untersucht:

  • [Anwendungsbasis] / [binpath] / [Assemblyname].dll

  • [Anwendungsbasis] / [bin-Pfad] / [Assemblyname] / [Assemblyname].dll

Beispiele einer Überprüfung

In Anbetracht der folgenden Informationen:

  • Name der Assembly, auf die verwiesen wird: myAssembly

  • Anwendungsstammverzeichnis: http://www.code.microsoft.com

  • <Probingelement> in der Konfigurationsdatei gibt folgendes an: bin

  • Kultur: de

Die Common Language Runtime überprüft die folgenden URLs:

  • http://www.code.microsoft.com/de/myAssembly.dll

  • http://www.code.microsoft.com/de/myAssembly/myAssembly.dll

  • http://www.code.microsoft.com/bin/de/myAssembly.dll

  • http://www.code.microsoft.com/bin/de/myAssembly/myAssembly.dll

Mehrere Assemblys mit dem gleichen Namen

Das folgende Beispiel zeigt, wie Sie mehrere Assemblys mit demselben Namen konfigurieren.

<dependentAssembly>
   <assemblyIdentity name="Server" publicKeyToken="c0305c36380ba429" />
   <codeBase version="1.0.0.0" href="v1/Server.dll" />
   <codeBase version="2.0.0.0" href="v2/Server.dll" />
</dependentAssembly>

Andere Standorte, die untersucht werden

Der Assembly-Standort kann auch über den aktuellen Bindungskontext bestimmt werden. Dies tritt am häufigsten auf, wenn die Assembly.LoadFrom Methode und in COM-Interoperabilitätsszenarien verwendet wird. Wenn eine Assembly die LoadFrom Methode verwendet, um auf eine andere Assembly zu verweisen, wird der Speicherort der aufrufenden Assembly als Hinweis auf den Speicherort der referenzierten Assembly betrachtet. Bei gefundener Übereinstimmung wird diese Assembly geladen. Besteht keine Übereinstimmung, setzt die Common Language Runtime die Suche mit der entsprechenden Semantik fort und fordert Windows Installer auf, die Assembly zur Verfügung zu stellen. Wenn keine Assembly zur Verfügung gestellt wird, die mit der Bindungsanforderung übereinstimmt, wird eine Ausnahme ausgelöst. Diese Ausnahme ist ein TypeLoadException in verwaltetem Code, wenn auf einen Typ verwiesen wurde, oder ein FileNotFoundException, wenn eine Assembly, die geladen werden sollte, nicht gefunden wurde.

Wenn Assembly1 beispielsweise auf Assembly2 verweist und Assembly1 von http://www.code.microsoft.com/utils heruntergeladen wurde, wird dieser Speicherort als Hinweis darauf betrachtet, wo Assembly2.dllzu finden ist. Die Runtime sucht in http://www.code.microsoft.com/utils/Assembly2.dll und http://www.code.microsoft.com/utils/Assembly2/Assembly2.dll nach der Assembly. Wenn Assembly2 an keinem dieser Speicherorte gefunden wird, fragt die Laufzeit den Windows Installer ab.

Siehe auch