Versammlung fand Referenz nicht, auch wenn die Montage im gleichen Verzeichnis ist

Question

Wir sind derzeit ein Add-in für einige Software zu entwickeln. Wir entschieden uns, in .NET zu entwickeln, auch wenn die Anwendung in einer Muttersprache geschrieben ist. Da es einige Probleme gab direkt die externe Schnittstelle in .NET erstellen, haben wir beschlossen, eine Brücke DLL in C ++ / CLI zu bauen, die einige grundlegende Initialisierung tut und dann Montage unserer verwalteten lädt und erstellt eine Benutzersteuerung aus, dass.

In einer Add-in INI-Datei, die C ++ / CLI-DLL wird durch Namen verwiesen, so dass die Anwendung von dort geladen werden. Der .NET-DLL wird jedoch nur von der C verweist ++ / CLI-DLL (als Managed-Referenz), so dass die ausgeführten Typen zur Verfügung stehen. In diesem Setup howerver, stürzt die Anwendung die .NET-DLL geladen wird.

Wir haben schnell festgestellt, dass wir nur auf das AppDomain.AssemblyResolve Ereignis abonnieren könnten die .NET-Assembly aus dem gleichen Verzeichnis zu laden, wo die C ++ / CLI-DLL ist, so das Problem selbst gelöst wird.

Die eigentliche Frage ist: Warum der Loader des .NET-DLL nicht finden, auch wenn es im selben Verzeichnis wie die Anordnung es werben? Ich erwartete immer, dass Ladeeinheiten werden zunächst in das gleiche Verzeichnis suchen, anstatt nur in das aktuelle Arbeitsverzeichnis. Warum findet ein ausführbare eine Baugruppe, wenn sie dann ihr Arbeitsverzeichnis ändern? Oder sind die Dinge anders, wenn die CLR-Assembly durch das Laden eines C ++ / CLI aufgerufen wird (und nicht als eine reine verwaltete Anwendung)?

Answer 1

Ich würde Sie empfehlen fuslogvw.exe zu verwenden, um Probleme dieser Art zu analysieren:

Fuslogvw.exe und Diagnose. NET Bindungsanordnung Fragen

Und natürlich, das Universalwerkzeug für Probleme mit Dateien nicht gefunden Analyse:

Process Monitor

Answer 2

Die Sondierung Weg für Baugruppen bekommen ein wenig unberechenbar zu sein, wenn ein nicht verwaltetes EXE den Prozess gestartet wird. Nur weil es sich um eine C ++ / CLI-DLL, vielleicht durch Loadlibrary oder SetDllDirectory geladen, funktioniert nicht in irgendeiner Weise den Sondierungs Pfad für die CLR.

Aber das ist nur raten. Es besteht keine Notwendigkeit zu erraten, wenn Sie die Ausgabe von Fuslogvw.exe hergestellt zu sehen. Es zeigt Ihnen genau, was sondiert wird und welche Richtlinien angewendet werden. Sie beheben das Problem mit einer app.exe.config Datei (Antastelement) oder in der Tat durch AssemblyResolve.