Qt für Windows – Bereitstellung

Diese Dokumentation beschreibt den Bereitstellungsprozess für Windows. Zur Veranschaulichung des Bereitstellungsprozesses beziehen wir uns im gesamten Dokument auf die Beispielanwendung „Plug & Paint “.

Das Windows-Bereitstellungstool

Die empfohlene und einfachste Methode zur Bereitstellung einer Qt-Anwendung unter Windows ist die Verwendung des Tools „windeployqt“, das automatisch alle erforderlichen Qt-Bibliotheken, Plugins, QML-Module und Laufzeitabhängigkeiten in einem einsatzbereiten Bereitstellungsordner zusammenfasst.

Es erstellt einen Installationsbaum für Windows-Desktop-Anwendungen, der sich problemlos zu einem Installationspaket bündeln lässt.

Einrichten der Build-Umgebung

Wenn Sie Qt über Qt Online Installer installiert haben, müssen Sie die Build-Umgebung einrichten, bevor Sie windeployqt ausführen. Führen Sie dazu folgenden Befehl aus:

<qt-installation-folder>/bin/qtenv2.bat

Verwendung

„windeployqt“ befindet sich unter <qt-installation-folder>/bin/. Es erwartet als Argument eine „ .exe “-Datei oder ein Verzeichnis, das eine „ .exe “-Datei enthält, und scannt die ausführbare Datei auf Abhängigkeiten.

Beachten Sie Folgendes:

• Wird mit dem Argument „ --qmldir “ ein Verzeichnis übergeben, verwendet windeployqt das Tool „qmlimportscanner“, um die QML-Dateien in diesem Verzeichnis auf QML-Import-Abhängigkeiten zu überprüfen. Die identifizierten Abhängigkeiten werden anschließend in das Verzeichnis der ausführbaren Datei kopiert.
• Wurde Qt mit deaktiviertem Konfigurationsschalter „ -relocatable “ erstellt, ersetzt windeployqt die fest codierten lokalen Pfade in „ Qt6Core.dll “ durch relative Pfade.
• Bei Windows-Desktop-Anwendungen kopiert windeployqt standardmäßig die erforderlichen Compiler-Laufzeitdateien, sofern nicht „ --no-compiler-runtime “ angegeben ist. Bei Release-Builds mit Microsoft Visual C++ bedeutet dies, dass das Tool davon ausgeht, dass der Anwendungsinstallierer die offiziellen Visual C++ Redistributable Packages enthält.

  Ist das Redistributable nicht verfügbar, greift windeployqt möglicherweise auf die gemeinsam genutzten Laufzeit-DLLs des Compilers zurück, die sich auf dem Entwicklerrechner befinden. Diese einzelnen DLLs sind nicht für die Weitergabe vorgesehen und nicht entsprechend lizenziert; sie sollten daher nicht direkt ausgeliefert werden. Für die Bereitstellung auf Endbenutzersystemen sollte ausschließlich das offizielle Microsoft-Redistributable-Installationsprogramm verwendet werden.

Häufige Anwendungsfälle

Bereitstellung einer Standard- Qt Widgets -Anwendung

windeployqt.exe .\build\MyApp.exe

Bereitstellung einer „ Qt Quick “-Anwendung mit QML-Quelldateien

windeployqt.exe --qmldir .\qml .\build\MyApp.exe

Erstellen eines appx-Manifests für die Paketierung

Verwenden Sie diese Option, wenn Sie Ihre Anwendung für die Verpackung als Windows-Appx-Paket vorbereiten.

Die Option „ --appx “ erstellt ein „ AppxManifest.xml “, und „ --appx-certificate “ gibt das Zertifikat an, das in das Manifest eingebettet werden soll.

windeployqt.exe --appx --appx-certificate MyCompany.cer .\build\MyApp.exe

Durchführen eines Testlaufs

Ein Testlauf simuliert die Bereitstellung, ohne dass Daten kopiert oder aktualisiert werden.

windeployqt.exe --dry-run MyApp.exe

Optionen

Allgemein

Eingabe- und Ausgabesteuerung

Qt-Pfadauflösung

Build-Konfiguration

Verhalten bei der Bereitstellung

Plugins

QML

Übersetzungen

System- und Laufzeitkomponenten

Ausgabe der Dateiliste

Statische Verknüpfung

Um statische Anwendungen zu erstellen, müssen Sie Qt statisch kompilieren, indem Sie Qt mit der Option „ -static “ konfigurieren:

cd C:\path\to\Qt
configure -static <any other options you need>

Falls Sie Qt später vom selben Speicherort aus neu konfigurieren und neu kompilieren müssen, stellen Sie sicher, dass alle Spuren der vorherigen Konfiguration entfernt wurden.

Die Anwendung mit der statischen Version von Qt verknüpfen

In diesem Abschnitt wird als Beispiel das „Plug & Paint “-Beispiel mit einem statisch kompilierten Qt erstellt.

Sobald die Kompilierung von Qt abgeschlossen ist, kompilieren Sie die „Plug & Paint“-Anwendung. In diesem Abschnitt wird davon ausgegangen, dass die statisch kompilierte Qt-Version unter C:\path\to \static \Qt installiert wurde. Zunächst müssen wir in das Verzeichnis wechseln, das die Anwendung enthält:

cd examples\tools\plugandpaint

Nun erstellen wir ein Build-Verzeichnis und rufen „ qt-cmake “ auf, um die Dateien des Build-Systems zu generieren.

md build_static
cd build_static
C:\path\to\static\Qt\bin\qt-cmake .. -DCMAKE_BUILD_TYPE=Release -GNinja
ninja

Wahrscheinlich möchten Sie gegen die Release-Bibliotheken verknüpfen; dies haben wir mit der Variablen ` CMAKE_BUILD_TYPE ` festgelegt. Vorausgesetzt, dass alles fehlerfrei kompiliert und verknüpft wurde, sollten wir nun über eine Datei ` plugandpaint.exe ` verfügen, die für die Bereitstellung bereit ist. Um zu überprüfen, ob die Anwendung über die erforderlichen Bibliotheken verfügt, kopieren Sie die ausführbare Datei auf einen Rechner, auf dem weder Qt noch Qt-Anwendungen installiert sind, und führen Sie sie dort aus.

Beachten Sie, dass, falls Ihre Anwendung von kompilatorspezifischen Bibliotheken abhängt, diese weiterhin zusammen mit Ihrer Anwendung weiterverbreitet werden müssen. Mit dem Tool „ depends “ können Sie überprüfen, mit welchen Bibliotheken Ihre Anwendung verknüpft ist. Weitere Informationen finden Sie im Abschnitt „Anwendungsabhängigkeiten “.

Da wir Plugins nicht mithilfe der statischen Verknüpfung bereitstellen können, ist die von uns vorbereitete Anwendung unvollständig. Sie lässt sich zwar ausführen, die Funktionalität ist jedoch aufgrund der fehlenden Plugins deaktiviert. Um pluginbasierte Anwendungen bereitzustellen, sollten wir den Ansatz mit gemeinsam genutzten Bibliotheken verwenden.

Gemeinsam genutzte Bibliotheken

Bei der Bereitstellung der Anwendung „ plugandpaint “ mithilfe des Shared-Libraries-Ansatzes stehen wir vor zwei Herausforderungen: Die Qt-Laufzeitumgebung muss zusammen mit der ausführbaren Anwendungsdatei korrekt weiterverteilt werden, und die Plugins müssen am richtigen Speicherort auf dem Zielsystem installiert werden, damit die Anwendung sie finden kann.

Qt als gemeinsam genutzte Bibliothek erstellen

Für dieses Beispiel gehen wir davon aus, dass Qt als gemeinsam genutzte Bibliothek installiert ist – was bei der Installation von Qt die Standardeinstellung ist – und sich im Verzeichnis „C:\path\to \Qt “ befindet.

Die Anwendung mit Qt als gemeinsam genutzte Bibliothek verknüpfen

Nachdem wir sichergestellt haben, dass Qt als gemeinsam genutzte Bibliothek erstellt wurde, können wir die Anwendung „ plugandpaint “ erstellen. Zunächst müssen wir in das Verzeichnis wechseln, das die Anwendung enthält:

cd examples\tools\plugandpaint

Erstellen Sie nun ein eigenes Build-Verzeichnis und führen Sie „ qt-cmake “ aus, um die Dateien des Build-Systems zu erstellen:

md build_shared
cd build_shared
C:\path\to\Qt\bin\qt-cmake .. -DCMAKE_BUILD_TYPE=Release -GNinja
ninja

Wenn alles ohne Fehler kompiliert und verknüpft wurde, erhalten wir die ausführbare Datei „ plugandpaint.exe “ sowie die Plugin-Dateien „ pnp_basictools.dll “ und „ pnp_extrafilters.dll “.

Erstellen des Anwendungspakets

Um die Anwendung bereitzustellen, müssen wir sicherstellen, dass wir die relevanten Qt-DLLs (entsprechend den in der Anwendung verwendeten Qt-Modulen) und das Windows-Plattform-Plugin „ qwindows.dll “ sowie die ausführbare Datei in denselben Verzeichnisbaum im Unterverzeichnis „ release “ kopieren.

Im Gegensatz zu Benutzer-Plugins müssen Qt-Plugins in Unterverzeichnissen abgelegt werden, die dem Plugin-Typ entsprechen. Der richtige Speicherort für das Plattform-Plugin ist ein Unterverzeichnis mit dem Namen „ platforms “. Im Abschnitt „Qt-Plugins“ finden Sie weitere Informationen zu Plugins und dazu, wie Qt nach ihnen sucht.

Wenn dynamisches OpenGL verwendet wird, sollten Sie zusätzlich die für softwaremäßiges OpenGL erforderliche Bibliothek einbinden, sofern die Anwendung damit kompatibel ist.

Wenn Qt so konfiguriert wurde, dass es gegen ICU oder OpenSSL verknüpft wird, müssen die entsprechenden DLLs möglicherweise ebenfalls in den Ordner „ release “ kopiert werden. Bei den Binärpaketen für Qt unter Windows ist dies jedoch nicht erforderlich. Wenn Sie Qt mit einer bestimmten Version von ICU oder OpenSSL konfiguriert haben, sollte windeployqt die DLLs der jeweiligen Bibliotheken übernehmen, sofern diese im Verzeichnis „ [bin] “ von Qt zu finden sind. Weitere Details finden Sie auch unter „Bibliotheken von Drittanbietern“.

Beachten Sie, dass, wenn Ihre Anwendung von kompilatorspezifischen Bibliotheken abhängt, diese zusammen mit Ihrer Anwendung weiterverbreitet werden müssen. Mit dem Tool „ depends “ können Sie überprüfen, mit welchen Bibliotheken Ihre Anwendung verknüpft ist. Weitere Informationen finden Sie im Abschnitt „Anwendungsabhängigkeiten “.

Wir werden in Kürze auf die Plugins eingehen, aber zunächst überprüfen wir, ob die Anwendung in einer Produktionsumgebung funktioniert: Kopieren Sie entweder die ausführbare Datei und die Qt-DLLs auf einen Rechner, auf dem weder Qt noch Qt-Anwendungen installiert sind, oder stellen Sie, falls Sie auf dem Build-Rechner testen möchten, sicher, dass sich Qt nicht in der Umgebung dieses Rechners befindet.

Wenn die Anwendung ohne Probleme startet, haben wir erfolgreich eine dynamisch verknüpfte Version der Anwendung „ plugandpaint “ erstellt. Die Funktionalität der Anwendung fehlt jedoch noch, da wir die zugehörigen Plugins noch nicht bereitgestellt haben.

Plugins funktionieren anders als normale DLLs, daher können wir sie nicht einfach in dasselbe Verzeichnis wie die ausführbare Datei unserer Anwendung kopieren, wie wir es bei den Qt-DLLs getan haben. Bei der Suche nach Plugins durchsucht die Anwendung ein Unterverzeichnis „ plugins “ innerhalb des Verzeichnisses der ausführbaren Anwendungsdatei.

Um die Plugins für unsere Anwendung verfügbar zu machen, müssen wir also das Unterverzeichnis „ plugins “ anlegen und die entsprechenden DLLs dorthin kopieren:

plugins\pnp_basictools.dll
plugins\pnp_extrafilters.dll

Ein Archiv, das alle Qt-DLLs und anwendungsspezifischen Plugins enthält, die zum Ausführen der „Plug & Paint “-Anwendung erforderlich sind, müsste die folgenden Dateien umfassen:

Je nach den von der Anwendung genutzten Funktionen sind möglicherweise weitere Plugins erforderlich (iconengines, imageformats).

Darüber hinaus muss das Archiv die folgenden compilerspezifischen Bibliotheken enthalten (unter der Annahme, dass Visual Studio 17 (2022) verwendet wird):

Wenn dynamisches OpenGL verwendet wurde, kann das Archiv zusätzlich Folgendes enthalten:

Wenn Qt für die Verwendung von ICU konfiguriert wurde, muss das Archiv außerdem Folgendes enthalten:

Um zu überprüfen, ob die Anwendung nun erfolgreich bereitgestellt werden kann, können Sie dieses Archiv auf einem Rechner entpacken, auf dem weder Qt noch ein Compiler installiert ist, und versuchen, es auszuführen.

Eine Alternative zum Ablegen der Plugins im Unterverzeichnis „plugins“ besteht darin, beim Starten Ihrer Anwendung mit ` QCoreApplication::addLibraryPath()` oder ` QCoreApplication::setLibraryPaths()` einen benutzerdefinierten Suchpfad hinzuzufügen.

QCoreApplication::addLibraryPath("C:/some/other/path");

Ein Vorteil der Verwendung von Plugins besteht darin, dass sie problemlos einer ganzen Familie von Anwendungen zur Verfügung gestellt werden können.

Oft ist es am bequemsten, den Pfad in der Funktion ` main() ` der Anwendung hinzuzufügen, unmittelbar nachdem das ` QApplication `-Objekt erstellt wurde. Sobald der Pfad hinzugefügt wurde, durchsucht die Anwendung diesen nach Plugins, zusätzlich zur Suche im Unterverzeichnis ` plugins ` im eigenen Verzeichnis der Anwendung. Es können beliebig viele weitere Pfade hinzugefügt werden.

Erstellung des Windows-Anwendungsmanifests

Beim Erstellen unter Windows generiert Qt automatisch ein Anwendungsmanifest für ausführbare Ziele und bettet dieses ein.

Das generierte Manifest:

• erklärt die Kompatibilität mit Windows 10 und Windows 11
• Ermöglicht die Verarbeitung langer Pfade
• Legt die Anwendungsversion fest (aus PROJECT_VERSION)
• Definiert eine Projektkennung
• Konfiguriert die angeforderte Ausführungsstufe
• Deaktiviert das standardmäßig vom Linker generierte Manifest (/MANIFEST:NO)

Wenn in den Zielquellen bereits eine benutzerdefinierte „ .manifest “-Datei vorhanden ist, überschreibt Qt diese nicht.

Durch die Deklaration der Windows 10/11-Kompatibilität wird das moderne Windows-Verhalten aktiviert, einschließlich:

• Aktivierung des modernen Verhaltens des Fenstermanagers
• Unterstützung für „ WS_EX_LAYERED “ bei untergeordneten Fenstern (wird seit Windows 8 unterstützt, ist jedoch durch Kompatibilitätsprüfungen eingeschränkt)
• Unterstützung für lange Pfade (> 260 Zeichen)
• Explizite Konfiguration der Ausführungsstufe

Ohne eine entsprechende Kompatibilitätserklärung wendet Windows möglicherweise das alte Verhalten auf die Anwendung an.

Standardinhalt des Manifests

Anwendungsidentität

Das Manifest enthält ein „ assemblyIdentity “-Element:

<assemblyIdentity
    type="win32"
    name="com.yourcompany.myapp"
    version="1.0.0.0"
    processorArchitecture="*" />

• name — Projektkennung
• version — normiert auf eine vierteilige Windows-Version

Standardmäßig lautet die Kennung:

com.yourcompany.<target_name>

Er kann pro Ziel mithilfe der Eigenschaft „ QT_WINDOWS_APP_PROJECT_IDENTIFIER “ überschrieben werden:

set_target_properties(myapp PROPERTIES
    QT_WINDOWS_APP_PROJECT_IDENTIFIER "org.example.myapp"
)

Windows-Anwendungsmanifeste erfordern eine vierteilige Versionsnummer:

Major.Minor.Build.Revision

Jeder Teil muss eine ganze Zahl im Bereich von 0 bis 65535 sein.

Der Wert wird aus „ PROJECT_VERSION “ abgeleitet und wie folgt normiert:

• Falls fehlend → Standardwert 1.0.0.0
• Weniger als vier Segmente → mit Nullen aufgefüllt
• Mehr als vier Segmente → gekürzt
• Werte < 0 → auf 0 begrenzt
• Werte > 65535 → auf 65535 begrenzt (Warnung ausgegeben)

Beispiele:

2.3        -> 2.3.0.0
1.2.3.4.5  -> 1.2.3.4
70000.1    -> 65535.1.0.0

Windows-Kompatibilität

Das Manifest gibt an, dass Windows 10 und Windows 11 unterstützt werden.

<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} Die GUID entspricht folgenden Betriebssystemen: Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 und Windows Server 2022.

Weitere Informationen finden Sie unter: Microsoft-Anwendungsmanifeste.

Unterstützung für lange Pfade

<ws2:longPathAware>true</ws2:longPathAware>

Ermöglicht die Verwendung von Dateipfaden, die länger als 260 Zeichen sind, sofern dies vom Betriebssystem unterstützt wird.

Ausführungsebene

<requestedExecutionLevel level="asInvoker" uiAccess="false" />

Die Standardstufe ist „ asInvoker “.

Um die Ausführungsebene festzulegen, verwenden Sie die Eigenschaft „ QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL “.

Gültige Werte:

• asInvoker (Standard)
• highestAvailable
• requireAdministrator

Beispiel:

set_target_properties(myapp PROPERTIES
    QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL "requireAdministrator"
)

Wird ein ungültiger Wert angegeben, wird eine Warnung ausgegeben und „ asInvoker “ verwendet.

Bereitstellen eines benutzerdefinierten Manifests

Qt erkennt die Manifestdatei und überspringt die automatische Generierung, wenn eine ausführbare Datei bereits eine „ .manifest “-Datei in ihren Quellcode enthält:

add_executable(myapp
    main.cpp
    myapp.manifest
)

Vollständiges Beispiel

Das folgende Beispiel zeigt eine Windows-Ausführungsdatei, die das automatisch generierte Manifest mit angepasstem Identifikator und Ausführungsstufe verwendet:

cmake_minimum_required(VERSION 3.21)
project(MyApp VERSION 2.5.1)

find_package(Qt6 REQUIRED COMPONENTS Core Widgets)

qt_add_executable(MyApp
    main.cpp
)

set_target_properties(MyApp PROPERTIES
    QT_WINDOWS_APP_PROJECT_IDENTIFIER "org.example.myapp"
    QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL "highestAvailable"
)

In diesem Beispiel lautet die Version des generierten Manifests:

2.5.1.0

Manifest-Dateien mit qmake

Bei der Bereitstellung einer mit Visual Studio kompilierten Anwendung sind einige zusätzliche Schritte erforderlich.

Zunächst müssen wir die beim Verknüpfen der Anwendung erstellte Manifestdatei kopieren. Diese Manifestdatei enthält Informationen über die Abhängigkeiten der Anwendung von Side-by-Side-Assemblies, wie beispielsweise den Laufzeitbibliotheken.

Die Manifestdatei muss in denselben Ordner wie die ausführbare Datei der Anwendung kopiert werden. Die Manifestdateien für gemeinsam genutzte Bibliotheken (DLLs) müssen nicht kopiert werden, da diese nicht verwendet werden.

Wenn die gemeinsam genutzte Bibliothek Abhängigkeiten aufweist, die sich von denen der Anwendung unterscheiden, die sie verwendet, muss die Manifestdatei in die DLL-Binärdatei eingebettet werden. Für das Einbetten von Manifesten stehen die folgenden Optionen in „ CONFIG “ zur Verfügung:

embed_manifest_dll
embed_manifest_exe

Beide Optionen sind standardmäßig aktiviert. Um „ embed_manifest_exe “ zu entfernen, fügen Sie Folgendes hinzu:

CONFIG -= embed_manifest_exe

in Ihre .pro-Datei ein.

Weitere Informationen zu Manifestdateien und Side-by-Side-Assemblies finden Sie auf der Dokumentationsseite zu Side-by-Side-Assemblies.

Die richtige Vorgehensweise, um die Laufzeitbibliotheken in Ihre Anwendung einzubinden, besteht darin, sicherzustellen, dass sie auf dem System des Endbenutzers installiert sind.

Um die Laufzeitbibliotheken auf dem System des Endbenutzers zu installieren, müssen Sie die entsprechende ausführbare Datei des Visual C++ Redistributable Package (VCRedist) in Ihre Anwendung einbinden und sicherstellen, dass sie ausgeführt wird, wenn der Benutzer Ihre Anwendung installiert.

Das Redistributable trägt den Namen „ vc_redist.x64.exe “ (64-Bit) und befindet sich im Ordner „ <Visual Studio install path>/VC/redist/<language-code> “.

Alternativ kann es aus dem Internet heruntergeladen werden, zum Beispiel unter https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads.

Anwendungsabhängigkeiten

Zusätzliche Bibliotheken

Je nach Konfiguration müssen kompilatorspezifische Bibliotheken zusammen mit Ihrer Anwendung weiterverbreitet werden.

Mit dem Tool „Dependency Walker“ können Sie überprüfen, mit welchen Bibliotheken Ihre Anwendung verknüpft ist. Dazu müssen Sie es lediglich wie folgt ausführen:

depends <application executable>

Dadurch erhalten Sie eine Liste der Bibliotheken, von denen Ihre Anwendung abhängt, sowie weitere Informationen.

Wenn man die Release-Version der „Plug & Paint“-Ausführungsdatei (plugandpaint.exe) mit dem Tool „ depends “ untersucht, listet das Tool die folgenden direkten Abhängigkeiten von Nicht-System-Bibliotheken auf:

Bei Betrachtung der Plugin-DLLs werden genau dieselben Abhängigkeiten aufgeführt.

Qt-Plugins

Alle „ Qt GUI “-Anwendungen benötigen ein Plugin, das die Qt Platform Abstraction (QPA)-Schicht in Qt implementiert. Unter Windows lautet der Name des Plattform-Plugins „ qwindows.dll “. Diese Datei muss sich in einem bestimmten Unterverzeichnis (standardmäßig „ platforms “) unterhalb Ihres Distributionsverzeichnisses befinden. Alternativ ist es möglich, den Suchpfad anzupassen, den Qt zum Auffinden seiner Plugins verwendet, wie im Folgenden beschrieben.

Ihre Anwendung kann zudem von einem oder mehreren Qt-Plugins abhängig sein, wie beispielsweise dem Qt Print Support-Plugin, dem JPEG-Bildformat-Plugin oder einem SQL-Treiber-Plugin. Stellen Sie sicher, dass Sie alle benötigten Qt-Plugins zusammen mit Ihrer Anwendung verteilen. Ähnlich wie beim Plattform-Plugin muss sich jeder Plugin-Typ in einem bestimmten Unterverzeichnis (z. B. printsupport, imageformats oder sqldrivers) innerhalb Ihres Verteilungsverzeichnisses befinden.

Die Bibliotheken sind verschiebbar, es sei denn, Qt wurde mit dem deaktivierten Konfigurationsschalter -relocatable kompiliert. Die Suchpfade für Qt-Plugins beziehen sich relativ auf den Speicherort der Bibliothek „ QtCore “, und es sind keine weiteren Schritte erforderlich, um sicherzustellen, dass die Plugins nach der Installation der Anwendung auf dem Zielrechner gefunden werden.

Sicherstellen, dass Plugins bei der Verwendung nicht verschiebbarer Builds gefunden werden

Bei nicht verschiebbaren Builds müssen zusätzliche Schritte unternommen werden, um sicherzustellen, dass die Plugins nach der Installation der Anwendung auf dem Zielrechner gefunden werden.

In diesem Fall ist der Suchpfad für Qt-Plugins fest in der Bibliothek „ QtCore “ hinterlegt. Standardmäßig ist das Unterverzeichnis „plugins“ der Qt-Installation der erste Suchpfad für Plugins. Vorab festgelegte Pfade wie der Standardpfad haben jedoch gewisse Nachteile. Beispielsweise sind sie auf dem Zielrechner möglicherweise nicht vorhanden. Aus diesem Grund müssen Sie verschiedene Alternativen prüfen, um sicherzustellen, dass die Qt-Plugins gefunden werden:

• Verwendung von ` qt.conf `. Dieser Ansatz wird empfohlen, wenn Sie ausführbare Dateien an verschiedenen Orten haben, die dieselben Plugins gemeinsam nutzen.
• Verwenden Sie „ QApplication::addLibraryPath “ () oder „ QApplication::setLibraryPaths “ (). Dieser Ansatz wird empfohlen, wenn Sie nur eine ausführbare Datei haben, die das Plugin verwendet.
• Verwenden Sie ein Installationsprogramm eines Drittanbieters, um die fest codierten Pfade in der Bibliothek „ QtCore “ zu ändern.

Wenn Sie mit `QApplication::addLibraryPath` einen benutzerdefinierten Pfad hinzufügen, könnte dies wie folgt aussehen:

QCoreApplication::addLibraryPath("C:/customPath/plugins");

Dann würde ` QCoreApplication::libraryPaths()` etwa Folgendes zurückgeben:

• C:/customPath/plugins
• C:/Qt/%VERSION%/plugins
• E:/myApplication/directory

Die ausführbare Datei sucht in diesen Verzeichnissen nach den Plugins, und zwar in derselben Reihenfolge, wie sie von ` QCoreApplication::libraryPaths()` als ` QStringList ` zurückgegeben wird. Der neu hinzugefügte Pfad wird dem ` QCoreApplication::libraryPaths()` vorangestellt, was bedeutet, dass dieser zuerst durchsucht wird. Wenn Sie jedoch ` QCoreApplication::setLibraryPaths()` verwenden, können Sie festlegen, welche Pfade in welcher Reihenfolge durchsucht werden sollen.

Das Dokument „How to Create Qt Plugins“ beschreibt die Punkte, auf die Sie beim Erstellen und Bereitstellen von Plugins für Qt-Anwendungen achten müssen.