2009-05-15 13 views
5

Ich habe ein Plug-in für eine Anwendung von einer anderen Firma. Mein Plug-in verwendet Qt, so dass es die Qt-DLLs benötigt. Mein Problem ist, dass alle Versionen von 4.x Qt Dlls die gleichen, z. : QtCore4.dll. Es ist durchaus möglich, dass ein anderes Plugin oder eine andere Anwendung, die sich selbst in die PATH-Umgebungsvariable eingefügt hat, Qt-DLLs in den Anwendungsordner gelegt hat. In diesem Fall wird das Plug-In nicht gestartet, da es eine andere Version der DLL erwartet.Qt DLL-Bereitstellung unter Windows

  • Q1. Was ist die empfohlene Vorgehensweise für die DLL-Bereitstellung?
  • Q2. Was ist, wenn die Host-Anwendung eine andere Version von Qt verwendet? Würden Windows der Host-Anwendung und dem Plug-in erlauben, verschiedene Versionen() zu verwenden?

Vielen Dank!

Antwort

0

Gibt es keine Möglichkeit, statisch mit Qt zu verknüpfen?

Ich würde die DLLs im selben Verzeichnis wie meine App/Plugin bereitstellen.

Dies beantwortet jedoch nicht Ihre anderen Bedenken.

+0

Soweit ich weiß, ist statisches Linken nur für eine kommerzielle Qt-Lizenz erlaubt. Die LGPL-Lizenz erfordert, dass Ihre Kunden Ihre Anwendung mit einer neuen Version von Qt verknüpfen können, was in der Praxis bedeutet: Geben Sie entweder die Quell- oder Objektdateien Ihrer Anwendung frei. Oder verteilen Sie Qt als DLLs. – Patrick

0

Wie Tim sagte, Sie sollten die DLLs im selben Verzeichnis wie die App/das Plugin, die Sie erstellen, bereitstellen. Ich glaube, dass die PATH-Variable nicht der erste Ort ist, an dem Ihr Programm nach der QT4-DLL sucht. Wenn Sie es also im selben Ordner bereitstellen, wird Ihre App die mit Ihrer App aufnehmen und alle auf dem PATH ignorieren.

Q1: In der Vergangenheit schien es so, als hätten alle ihre DLLs in den Ordner system32 geworfen, weil sie wussten, dass es auf dem PATH war und wussten, dass das Programm es finden konnte. Aus der Sicht des Anwenders finde ich das sehr schwer aufzuräumen, wenn ich etwas deinstallieren möchte. Und jetzt mit dem kleinen Preis für Speicher würde ich sagen, halten Sie Ihre DLLs mit Ihrer App, besonders wenn sie so sind, wo es mehrere Versionen geben könnte. Während ich kein Experte bin, behandle ich so JAR-Dateien für Java-Anwendungen.

Q2: Ich denke schon. Es hängt von der Verzeichnisstruktur der App und des Plugins ab. Du kannst deinem Plugin mitteilen, welche Version benutzt werden soll und ich wette, die App hat ihre Version bereits an einem speziellen Ort.

1

Mit Versionen von Windows seit XP (d. H. XP, 2003, Vista, 2008 und Win7) können Sie die side-by-side assemblies oder DLL redirection verwenden. In beiden Fällen enthalten Sie im Wesentlichen eine kleine Textdatei, die dem Betriebssystem mitteilt, dass Sie die spezifische Version der DLLs verwenden müssen, die Sie im selben Verzeichnis wie die ausführbare Datei gespeichert haben.

Dies sind weniger bekannte Funktionen, aber sie können wirklich Ihren Hintern aus "DLL Hell" speichern.

+0

Der Side-by-Side-Cache erschwert die Bereitstellung der Anwendung in einem großen Netzwerk. Ich bevorzuge einfache, zero-install, xcopy-install-Anwendungen, wo Sie nur die exe und einige DLLs kopieren müssen, oder Sie müssen es nicht sogar kopieren, aber nur auf einem Netzlaufwerk lassen. Mit den Side-by-Side-Cache-DLLs müssen Sie die Anwendung explizit auf jedem PC installieren. Und wenn die nächste Version neue DLLs benötigt, müssen Sie die Anwendung auch neu installieren. – Patrick

3

A1: Best Practice: Legen Sie die DLL in das Verzeichnis der ausführbaren Datei. Dort wird zuerst nach dem Laden der DLL gesucht. Dies ist gängige Praxis.

A2: Wenn die Anwendung irgendwie eine andere Version von Qt verwendet und das Modul, das Sie beschreiben, eine spätere oder spezifische Version benötigt, kann dies ein Problem verursachen (nicht funktionieren, Absturz usw.).

Mit statischem Linking müssten Sie auch Lizenzeinschränkungen von Qt berücksichtigen. LGPL ist glücklich, solange die Bibliothek zur Laufzeit dynamisch geladen wird und von der Anwendung getrennt werden kann. Dies gilt nur, wenn Sie Ihre Quelle nicht freigeben usw.

Außerdem sollte Ihr Installationsprogramm den Zugriff auf diese Dateien einrichten, damit sie vor dem Überschreiben durch eine andere Rogue-Anwendung geschützt sind.

3

Nur um anderen mit diesem Problem zu helfen: QT DLLs sind garantiert identisch (oder zumindest binär kompatibel) für alle 4.X Versionen. (Gleiches gilt für alle 3.X-Versionen und so weiter), also wird es kein Problem geben. Dies ist auch der Grund, warum es keine zweite Nummer in der Qt-DLL-Benennung gibt.

+3

Wenn jedoch die Konfiguration für zwei verschiedene Qt-Builds unterschiedlich ist, sind sie nicht binärkompatibel. – swongu

+0

Und was ist mit der 32-Bit- und 64-Bit-Version der QT-DLL? Dann sind sie auch nicht binär kompatibel. – Patrick

0

Zur Sicherheit müssen Sie sicherstellen, dass Ihre Anwendung die DLL-Versionen verwendet, die Sie verwenden möchten. Windows wird garantiert zuerst im Anwendungsordner suchen. Also sollten Sie alle Ihre binären Abhängigkeiten setzen.

Wenn Ihre Anwendung nicht ausgeführt wird, wenn Sie im Explorer doppelklicken, wird Windows Ihnen sagen, welche DLL es benötigt. Kopieren Sie diese DLL in den Anwendungsordner. Fahren Sie mit dem nächsten Schritt fort, wenn Ihre Anwendung ausgeführt wird.

Jetzt sollten Sie die DLLs nacheinander entfernen (oder umbenennen), die Sie im Anwendungsordner abgelegt haben und jedes Mal, wenn Sie Ihre Anwendung doppelklicken. Wenn Windows sich nicht beschwert, findet die DLL irgendwo anders. Holen Sie diese DLL aus der PATH-Umgebung (möglicherweise vorübergehend). Rapid Environment Editor ist ein kostenloses Dienstprogramm mit bearbeiteten Umgebungsvariablen, die sofort wirksam werden.

Nur wenn Sie sicher sind, dass Ihre Anwendung die DLLs im Anwendungsverzeichnis verwendet und keine DLL von einer anderen Stelle bezieht, können Sie die PATH-Variable erneut bearbeiten, um die alte Situation wiederherzustellen.

Verwandte Themen