.NET Assemblyen und DLL-Rebasing

Question

Laut diesem Artikel ist ein Neuverorten von .NET-Assemblys aufgrund der JIT-Kompilierung des Codes nicht erforderlich. Der Artikel besagt:

"JIT-kompilierter Code hat kein Neuverortungsproblem, da die Adressen zur Laufzeit generiert werden, basierend darauf, wo der Code im Speicher platziert ist. Außerdem werden MSIL selten von Basisadressfehlern beeinflusst, da MSIL-Verweise tokenbasiert sind und nicht adressbasiert. Daher ist das System bei der Verwendung des JIT-Compilers widerstandsfähig gegen Basisadresskonflikte."

Allerdings habe ich festgestellt, dass VS2008 allen Assemblys standardmäßig die Basisadresse 0x0400000 zuweist (Projekteigenschaften > Build > Erweitert) und wenn ich ein listdlls /r für meinen Prozess durchführe, werden tatsächlich alle meine .NET-Assemblys standardmäßig neu verortet.

Wenn ich die Adressen selbst zuweise, erfolgt kein Neuverorten.

Meine Frage lautet: Was wird in diesem Fall neu verortet und warum?

EDIT: Ich sollte hinzufügen, dass ich nicht von NGen-Assemblys spreche.

Answer 1

Das CLR-Ladeverfahren verwendet im Hintergrund LoadLibrary, also beobachten Sie folgendes: 2 Assemblys können nicht an der gleichen Adresse geladen werden. Was die Leute oft meinen, wenn sie versuchen, eine DLL neu zu basieren, ist, den Leistungseinbruch von Fix-ups zu vermeiden, z.B. müssen absolute Adressen und Funktionsaufrufe mit der geladenen Basisadresse "umplatziert" werden. CLR hat dieses Problem nicht (bin mir nicht sicher, ob statische Daten in der Anwendung, der zweite Teil dieser Fix-ups, ich müsste mich darüber informieren), da MSIL-Code bei Bedarf geladen wird, wenn Sie eine Funktion im verwalteten Code aufrufen. Der MSIL wird dann JIT-übersetzt und auf dem Heap platziert, einem anderen als dem normalen Objekt-Heap, glaube ich, auf die gleiche Weise, wie CLR neue Objekte in Ihrer Anwendung zuweist und anordnet.

Answer 2

Welches Betriebssystem verwenden Sie? Ich weiß, dass Vista und später ASLR eingeführt haben, das den Adressraum zufällig lädt, in den dlls geladen werden. Dies geschieht für System-DLLs, bin mir aber nicht sicher bei .net - vielleicht etwas, worüber man nachdenken sollte.