In x64-Anwendungen sieht es so aus, als ob einige Assemblys zweimal im Prozessadressraum zugeordnet werden. Die Assemblys werden von demselben Speicherort im selben Ladekontext geladen. Es gibt keine expliziten Reflektions-APIs oder App-Domänen.
Dies wird nicht für native DLLs oder Framework-DLLs mit systemeigenen Images (* .ni.dll) wiederholt, sondern für lokal erstellte Assemblys und andere wie System.Threading.Tasks.Dataflow.dll und StyleCop .dll.
Es wird nicht repropliziert, wenn die Lösung für x86 kompiliert wird.
Ich sehe die doppelten Einträge in Process Explorer und VMMap. Und wenn ich Modullast in Windbg breche, sehe ich ein anderes Verhalten, wenn x64 gegen x86 läuft.
Das Aufteilen der Baugruppen macht keinen Unterschied.
Um dies zu demonstrieren, habe ich eine Lösung zusammengestellt, die eine Assembly und eine ausführbare Datei erstellt, die auf diese Assembly verweist. Ich kann diesen Code zur Verfügung stellen, aber es ist absolut einfach: Die Assemblierung macht eine Enumeration verfügbar, und die EXE verweist auf einen Wert in dieser Enumeration und gibt sie aus.
Wenn ich sowohl Assembly als auch EXE-Targeting für x64 erstelle und die EXE ausführe, sehe ich doppelte Einträge in VMMap und Process Explorer. Beide zeigen, dass sich die referenzierten Assemblys auf demselben Pfad befinden. VMMap zeigt die Abschnitte .rsrc, .text und Header für beide Einträge an (zusammen mit 3 Reservierten Blöcken in jedem Eintrag).
Wenn ich genau dieselbe Lösung erstelle, die auf x86 abzielt und die EXE ausführt, sehe ich einen Eintrag für die Assembly in VMMap und Process Explorer.
Ich habe sowohl die 32-Bit- als auch die 64-Bit-Version unter windbg mit "sxe ld TestAssembly" ausgeführt, um die Last der fehlerhaften Baugruppe zu beobachten.
In den folgenden Stapeln sehen Sie, dass es in der 64-Bit-Version 3 und in der 32-Bit-Version nur 2 Unterbrechungen gibt.
Die ersten beiden Stapel in der 64-Bit-Version sehen ähnlich aus wie die zwei in der 32-Bit-Version, aber die dritte ist einzigartig für 64-Bit.
Irgendwelche Ideen, was hier passiert? Ich weiß 64bit ist 2x 32bit, aber ich habe nicht erwartet, dass die Baugruppen doppelt geladen werden! :)
Ich habe eine Lösung hochgeladen, um das Problem hier zu reproduzieren:
In dieser Zip-Datei sind die Repro-Schritte enthalten, aber wenn etwas nicht klar ist, lassen Sie es mich bitte wissen!
In 64 Bit sind hier die Stacks, wenn die Assembly unter windbg geladen wird (sxe ld TestAssembly):
%Vor%In 32 Bit sind hier die Stacks, wenn die Assembly unter windbg geladen wird (sxe ld TestAssembly):
%Vor%Hier sind die Informationen von VMMap, die eine Baugruppe zeigen, die zweimal im Prozess geladen wird, wobei die gleichen Abschnitte beide Male geladen werden.
%Vor%Update (20.Jan.2014):
Das CLR-Team hat auf meine Connect-Post :
"Vielen Dank, dass Sie dieses Problem gemeldet haben. Wir haben es für die nächste Hauptversion von .NET Framework behoben."