Unser Produkt enthält mehrere DLLs, die aus Open Source in Dateien mit Standardnamen wie von den Open-Source-Entwicklern erstellt wurden. Wir achten darauf, die Dateien in unseren eigenen Verzeichnissen zu installieren und den Suchpfad (nur für unsere Prozesse) sorgfältig zu verwalten, um den Loader glücklich zu machen.
Ein anderer Entwickler - ein hoch aufragender Intellekt - entschied, dass es einfacher wäre, einen eigenen Build von ein und derselben Open Source in C: \ WINDOWS unter denselben Standard-DLL-Dateinamen zu installieren. Wenn wir einen Prozess starten, der von diesen Open-Source-DLLs abhängt, durchsucht das System C: \ WINDOWS vor unseren Verzeichnissen und findet die DLLs, die vom anderen Entwickler installiert wurden. Und sie sind natürlich unvereinbar.
Ideen, die mir bisher eingefallen sind:
Aus verschiedenen Gründen ist keine dieser Optionen im Moment schmackhaft.
Was können wir noch tun, um uns gegen die hoch aufragenden Intellekts der Welt zu verteidigen?
Um zu den bereits ausgezeichneten Antworten hinzuzufügen, haben Sie ein paar weitere Möglichkeiten:
Die bevorzugte Lösung für dieses seit Windows XP unterstützte Problem besteht darin, Ihre DLLs in eine win32-Assembly umzuwandeln (Sie müssen nicht .NET sein, aber die Dokumentation zum Erstellen von win32-Assemblys mit starken Namen ist entsetzlich leicht) so ist es leicht zu verwirren und denke, das ist eine .NET-Technologie).
Eine Assembly erkennt komplizierter als einen Ordner (mit dem Namen der Assembly), der die DLLs und ein Manifest (mit dem Namen der Assembly) enthält, das ein assemblyIdentiy-Element und eine Anzahl von Dateiknoten für jede DLL enthält in der Versammlung.
Die assembly-basierte Suche funktioniert auch, wenn dlls statisch verknüpft sind!
Wenn sich die EXEs in verschiedenen Ordnern befinden, gibt es zwei Möglichkeiten, auf freigegebene Assemblys zuzugreifen:
Sie können Ihre Assemblys an einem privaten alternativen Speicherort speichern, wenn Sie erwarten, dass Ihre Anwendung unter Windows 7 und höher verwendet wird. Erstellen Sie eine Datei "app.exe.config" für jede exe-Datei und zeigen Sie auf probing privatePath -Element in einem allgemeinen Ordner, in dem Sie die Assemblys speichern.
Wenn Sie in Ordnung sind, administrativen Zugriff auf Installationen zu verlangen (über MSI), dann können Sie mit der entsetzlich schlechten Dokumentation (gut, fehlende Dokumentation) fertig werden, die Ihren Baugruppen einen starken Namen gibt, und dann speichern die Assembly in WinSxS.
Wenn Sie Ihre DLLs nicht als Assembly bündeln können oder wollen, Diese Seite behandelt die Dll-Suchreihenfolge
Die Verwendung von Funktionen wie SetDllDirectory hilft nur bei geladenen DLLs dynamisch zur Laufzeit (über LoadLibrary).
Dll Suchreihenfolge verwendet zu sein:
Was Sie zu Ihrem Vorteil hätten nutzen können: Starten Sie jede exe, indem Sie das "current" -Verzeichnis auf den Ordner mit den OSS-DLLs setzen.
Mit dem Erscheinen von SafeDllSearchMode lautet die Suchreihenfolge nun:
Bedeutung theres jetzt weniger Kontrolle als je :( - Es geht noch schneller zu den "nicht vertrauenswürdigen" c: \ windows & amp; System32 Ordner.
Auch hier wird LoadLibraryEx mit dem Flag LOAD_WITH_ALTERED_SEARCH_PATH die folgende Suchreihenfolge verursachen (vorausgesetzt, Sie übergeben einen vollständigen Pfad an LoadLibraryEx), wenn die erste DLL über LoadLibrary geladen wird und die abhängigen DLLs das Problem darstellen. p>
Sie haben nur zwei Optionen: Stellen Sie die DLL im selben Verzeichnis wie die EXE (hier wird Windows zuerst angezeigt) oder mithilfe von Manifesten, und stellen Sie die DLL im Side-by-Side-Cache von Windows bereit. Ich denke nicht, dass die letztere Option in der Open-Source-Welt üblich ist, aber es ist die einzige wirkliche Lösung, wenn Sie DLLs zwischen verschiedenen Apps teilen wollen.
Das Verzeichnis, von dem aus die Anwendung geladen wurde, ist normalerweise das erste Verzeichnis, das beim Laden einer DLL gesucht wird. Sie können jedoch SetDllDirectory verwenden, um die "alternative Suchreihenfolge" zu erhalten. In diesem Fall wird das Verzeichnis, das Sie für SetDllDirectory angeben, zuerst gesucht.
Es gibt auch eine SafeDllSearchMode , die das zu einem gewissen Grad beeinflusst. Wenn Sie es einschalten, wird das aktuelle Verzeichnis von der Suche ausgeschlossen.