Wie findet die .NET-Laufzeit nicht stark benannte Assemblys?

Question

Wir haben verschiedene Versionen von nicht stark benannten Assemblys und keine Bindung leitet sie in app.exe.config um. Zum Beispiel MyDll (1.0.0.0_null_neutral) und MyDll (2.0.0.0_null_neutral). Im Vergleich zu app.exe werden diese Assemblys in LAC \ MyDll_1.0.0.0_null_neutral und LAC \ MyDll_2.0.0.0_null_neutral gespeichert.

Mein Verständnis ist, dass die MyDll-Assemblies nicht stark benannt sind, die .NET-Laufzeit unterscheidet nicht zwischen verschiedenen Versionen von MyDll. Wenn MyDll 1.0.0.0 bereits in Arbeitsspeicher geladen wurde und wenn Code, der für MyDll 2.0.0.0 erstellt wurde, ausgeführt wurde, würde die .NET-Laufzeitumgebung daher MyDll 2.0.0.0 nicht laden.

Als ich jedoch den Prozess mit VS2008 anschloss und das Modulfenster sah, bemerkte ich, dass sowohl MyDll 1.0.0.0 als auch MyDll 2.0.0.0 aus dem LAC-Ordner geladen wurden.

Es scheint irgendwo eine Lücke in meinem Verständnis zu sein. Kann jemand bitte darauf hinweisen?

EDIT: Vielen Dank für die Antworten bisher. Ja, ich habe das bisschen übersprungen. Die ausführbare Datei überwacht das AssemblyResolve-Ereignis und behandelt es, indem sie in der LAC sucht.

Ich war mir ziemlich sicher, dass ich einige MSDN-Dokumentation gesehen habe, bevor diese Versionen ignoriert werden, es sei denn, eine Assembly hat einen starken Namen. Ich werde sehen, ob ich es ausgraben kann.

Answer 1

http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

Schritt 2 wird überprüft, ob es gewesen ist geladen, und das ist versionsspezifische, auch mit Artikeln, die nicht stark benannt sind.

Schritt 4 versucht, die Assembly durch Sondierung zu laden, und dies ist nicht versionsspezifisch.

Was ich verwirrt bin, ist, wenn Sie keine Informationen in Ihrer Konfigurationsdatei haben, wie ist es das Finden der DLL an erster Stelle? Ich denke, es gibt auch eine Lücke in meinem Verständnis :-).