- Qt 6.11
- Product information
- Supported Platforms
- Qt for Windows
- Qt for Windows - Deployment
- Qt 6.11.1 Reference Documentation

Graphics acceleration ◦ Specific issues

# Qt for Windows - Deployment

This documentation describes the deployment process for Windows. We refer to the Plug & Paint example application throughout the document to demonstrate the deployment process.

Note: Add your Qt build directory to the list of excluded directories of any anti-virus application that runs on your system.

## The Windows Deployment Tool

The recommended and easiest way to deploy a Qt application on Windows is to use the windeployqt tool, which automatically collects all required Qt libraries, plugins, QML modules, and runtime dependencies into a ready-to-run deployment folder.

It creates an installation tree for Windows desktop applications, which can be easily bundled into an installation package.

Note: The application may require additional 3rd-party libraries (for example, database libraries), which are not taken into account by windeployqt.

### Setting up the build environment

If you have installed Qt through Qt Online Installer, you must set up the build environment before you run windeployqt. To do this, run:

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

### Usage

windeployqt is located in `<qt-installation-folder>/bin/`, it takes an `.exe` file or a directory that contains an `.exe` file as an argument, and scans the executable for dependencies.

Note the following:

- If a directory is passed with the `--qmldir` argument, windeployqt uses the qmlimportscanner tool to scan QML files inside the directory for QML import dependencies. Identified dependencies are then copied to the executable's directory.
- If Qt was built with the configure switch `-relocatable` turned off, windeployqt replaces the hardcoded local paths in `Qt6Core.dll` with relative paths.
- For Windows desktop applications, windeployqt copies the required compiler runtime files by default unless `--no-compiler-runtime` is specified. For release builds using Microsoft Visual C++, this means the tool expects the application installer to include the official Visual C++ Redistributable Packages.

  If the redistributable is not available, windeployqt may fall back to using the compiler's shared runtime DLLs found on the developer machine. These individual DLLs are not intended or licensed for redistribution, and should not be shipped directly. Only the official Microsoft Redistributable installer should be used for deployment on end-user systems.

#### Common use cases

##### Deploying a standard Qt Widgets application

     windeployqt.exe .\build\MyApp.exe

##### Deploying a Qt Quick application with QML sources

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

##### Generating an appx manifest for packaging

Use this when preparing your application for packaging as a Windows appx package.

The `--appx` option creates an `AppxManifest.xml`, and `--appx-certificate` specifies the certificate to embed into the manifest.

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

##### Performing a dry run

A dry run simulates deployment without copying or updating anything.

     windeployqt.exe --dry-run MyApp.exe

#### Options

##### General

Option | Description
--- | ---
`-?`, `-h`, `--help` | Show help for command-line options.
`--help-all` | Show full help including generic Qt options.
`-v`, `--version` | Show version information.

##### Input and output control

Option | Description
--- | ---
`--dir <path>` | Use this directory as the deployment target instead of the binary directory.
`--libdir <path>` | Copy Qt libraries to this directory.
`--plugindir <path>` | Copy Qt plugins to this directory.
`--qml-deploy-dir <path>` | Copy QML files to this directory.
`--translationdir <path>` | Copy translations to this directory.

##### Qt path resolution

Option | Description
--- | ---
`--qtpaths <path>` | Use a specific `qtpaths.exe` file for resolving Qt locations.

##### Build configuration

Option | Description
--- | ---
`--debug` | Assume debug binaries.
`--release` | Assume release binaries.
`--pdb` | Deploy MSVC `.pdb` files.

##### Deployment behaviour

Option | Description
--- | ---
`--force` | Overwrite existing files.
`--dry-run` | Simulate deployment without copying or updating anything.
`--ignore-library-errors` | Continue even if some libraries are missing.
`--json` | Output deployment information in JSON format.
`--appx` | Create an `AppxManifest.xml` file for the Windows Store.
`--nopatchqt` | Skip patching the QtCore library.
`--no-libraries` | Skip library deployment.
`--verbose <level>` | Verbosity level (0–2).

##### Plugins

Option | Description
--- | ---
`--no-plugins` | Skip plugin deployment.
`--include-soft-plugins` | Include all relevant plugins based on soft dependencies.
`--skip-plugin-types <types>` | A comma-separate list of specific plugin categories to not add to deployment.
`--add-plugin-types <types>` | A comma-separate list of plugin types to add to deployment.
`--include-plugins <plugins>` | A comma-separate list of specific plugins (by name) to add to deployment.
`--exclude-plugins <plugins>` | A comma-separate list of specific plugins (by name) to not add to deployment.

##### QML

Option | Description
--- | ---
`--qmldir <directory>` | Scan for QML imports starting at this directory.
`--qmlimport <directory>` | Additional QML module search path.
`--no-quick-import` | Skip deployment of Qt Quick imports.

##### Translations

Option | Description
--- | ---
`--translations <languages>` | A comma-separated list of languages to deploy translations for.
`--no-translations` | Skip translations.

##### System and runtime components

Option | Description
--- | ---
`--no-system-d3d-compiler` | Skip system D3D compiler.
`--no-system-dxc-compiler` | Skip system DXC compiler.
`--compiler-runtime` | Deploy runtime compiler (Desktop only).
`--no-compiler-runtime` | Do not deploy runtime compiler (Desktop only).
`--no-opengl-sw` | Skip software OpenGL renderer.
`--no-ffmpeg` | Skip FFmpeg libraries.
`--force-openssl` | Deploy OpenSSL plugin but ignore library dependency.
`--openssl-root <directory>` | Directory containing OpenSSL libraries.
`--appx-certificate <.cer file>` | Path to appx certificate to sign appx package.

##### File list output

Option | Description
--- | ---

`--list <option>`

Print only filenames to stdout.

Options:

- `source`: absolute path of the source files.
- `target`: absolute path of the target files.
- `relative`: paths of the target files, relative to the target directory.
- `mapping`: outputs the source and the relative target, suitable for use within an Appx mapping file.

## Static Linking

To build static applications, build Qt statically by configuring Qt with `-static`:

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

If you later need to reconfigure and rebuild Qt from the same location, ensure that all traces of the previous configuration are removed.

### Linking the Application to the Static Version of Qt

As an example, this section will build the Plug & Paint example against a statically built Qt.

Once Qt finishes building, build the Plug & Paint application. This section assumes that the static Qt build has been installed to C:\path\to\static\Qt. First we must go into the directory that contains the application:

     cd examples\tools\plugandpaint

Now, we create a build directory and call `qt-cmake` to generate the build system files.

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

You probably want to link against the release libraries, and we specified this with the `CMAKE_BUILD_TYPE` variable. Now, provided that everything compiled and linked without any errors, we should have a `plugandpaint.exe` file that is ready for deployment. To check that the application has the required libraries, copy the executable to a machine that does not have Qt or any Qt applications installed, and run it on that machine.

Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. You can check which libraries your application is linking against by using the `depends` tool. For more information, read the Application Dependencies section.

Since we cannot deploy plugins using the static linking approach, the application we have prepared is incomplete. It will run, but the functionality will be disabled due to the missing plugins. To deploy plugin-based applications we should use the shared library approach.

## Shared Libraries

We have two challenges when deploying the `plugandpaint` application using the shared libraries approach: The Qt runtime has to be correctly redistributed along with the application executable, and the plugins have to be installed in the correct location on the target system so that the application can find them.

### Building Qt as a Shared Library

For this example, we assume that Qt is installed as a shared library, which is the default when installing Qt, in the C:\path\to\Qt directory.

### Linking the Application to Qt as a Shared Library

After ensuring that Qt is built as a shared library, we can build the `plugandpaint` application. First, we must go into the directory that contains the application:

     cd examples\tools\plugandpaint

Now create a dedicated build directory and run `qt-cmake` to create the build system files:

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

If everything compiled and linked without any errors, we will get a `plugandpaint.exe` executable and the `pnp_basictools.dll` and `pnp_extrafilters.dll` plugin files.

### Creating the Application Package

To deploy the application, we must make sure that we copy the relevant Qt DLLs (corresponding to the Qt modules used in the application) and the Windows platform plugin, `qwindows.dll`, as well as the executable to the same directory tree in the `release` subdirectory.

In contrast to user plugins, Qt plugins must be put into subdirectories matching the plugin type. The correct location for the platform plugin is a subdirectory named `platforms`. Qt Plugins section has additional information about plugins and how Qt searches for them.

If dynamic OpenGL is used, you may additionally want to include the library required software-based OpenGL, if the application is compatible with it.

If Qt was configured to link against ICU or OpenSSL, the respective DLL's might need to be added to the `release` folder, too. But the binary packages for Qt on Windows do not require this. If you configured Qt with a specific version of ICU or OpenSSL, windeployqt should pick up the DLL's of the respective libraries if they can be found inside Qt's `[bin]` directory. For more details, see also Third-Party Libraries.

Remember that if your application depends on compiler specific libraries, these must be redistributed along with your application. You can check which libraries your application is linking against by using the `depends` tool. For more information, see the Application Dependencies section.

We'll cover the plugins shortly, but first we'll check that the application will work in a deployed environment: Either copy the executable and the Qt DLLs to a machine that doesn't have Qt or any Qt applications installed, or if you want to test on the build machine, ensure that the machine doesn't have Qt in its environment.

If the application starts without any problems, then we have successfully made a dynamically linked version of the `plugandpaint` application. But the application's functionality will still be missing since we have not yet deployed the associated plugins.

Plugins work differently to normal DLLs, so we can't just copy them into the same directory as our application's executable as we did with the Qt DLLs. When looking for plugins, the application searches in a `plugins` subdirectory inside the directory of the application executable.

So to make the plugins available to our application, we have to create the `plugins` subdirectory and copy over the relevant DLLs:

     plugins\pnp_basictools.dll
     plugins\pnp_extrafilters.dll

An archive distributing all the Qt DLLs and application specific plugins required to run the Plug & Paint application, would have to include the following files:

Component | File Name
--- | ---
The executable | `plugandpaint.exe`
The Basic Tools plugin | `plugins\pnp_basictools.dll`
The ExtraFilters plugin | `plugins\pnp_extrafilters.dll`
The Qt Windows platform plugin | `platforms\qwindows.dll`
The Qt Windows Vista style plugin | `styles\qwindowsvistastyle.dll`
The Qt Core module | `Qt6Core.dll`
The Qt GUI module | `Qt6Gui.dll`
The Qt Widgets module | `Qt6Widgets.dll`

Other plugins might be required depending on the features the application uses (`iconengines`, `imageformats`).

In addition, the archive must contain the following compiler specific libraries (assuming Visual Studio 17 (2022)):

Component | File Name
--- | ---
The C run-time | `vcruntime140.dll`
The C++ run-time | `msvcp170.dll`

If dynamic OpenGL was used, then the archive may additionally contain:

Component | File Name
--- | ---
OpenGL Software renderer library | opengl32sw.dll

Finally, if Qt was configured to use ICU, the archive must contain:

File Name
icudtXX.dll | icuinXX.dll | icuucXX.dll

To verify that the application now can be successfully deployed, you can extract this archive on a machine without Qt and without any compiler installed, and try to run it.

An alternative to putting the plugins in the plugins subdirectory is to add a custom search path when you start your application using QCoreApplication::addLibraryPath() or QCoreApplication::setLibraryPaths().

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

One benefit of using plugins is that they can easily be made available to a whole family of applications.

It's often most convenient to add the path in the application's `main()` function, right after the QApplication object is created. Once the path is added, the application will search it for plugins, in addition to looking in the `plugins` subdirectory in the application's own directory. Any number of additional paths can be added.

## Windows Application Manifest Generation

When building on Windows, Qt automatically generates and embeds an application manifest for executable targets.

The generated manifest:

- Declares Windows 10 and Windows 11 compatibility
- Enables long path awareness
- Sets the application version (from `PROJECT_VERSION`)
- Defines a project identifier
- Configures the requested execution level
- Disables the default linker-generated manifest (`/MANIFEST:NO`)

If a custom `.manifest` file is already provided in the target sources, Qt does not override it.

Declaring Windows 10/11 compatibility enables modern Windows behavior, including:

- Opt-in to modern window manager behavior
- Support for `WS_EX_LAYERED` on child windows (supported since Windows 8 but gated by compatibility awareness)
- Long path support (> 260 characters)
- Explicit execution level configuration

Without an appropriate compatibility declaration, Windows may apply legacy behavior to the application.

### Default Manifest Contents

#### Application Identity

The manifest contains an `assemblyIdentity` element:

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

- `name` — project identifier
- `version` — normalized to a four-part Windows version

By default, the identifier is:

     com.yourcompany.<target_name>

It can be overridden per target using the `QT_WINDOWS_APP_PROJECT_IDENTIFIER` property:

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

Windows application manifests require a four-part version number:

     Major.Minor.Build.Revision

Each segment must be an integer in the range 0–65535.

The value is derived from `PROJECT_VERSION` and normalized as follows:

- If missing → defaults to `1.0.0.0`
- Fewer than four segments → padded with zeros
- More than four segments → truncated
- Values < 0 → clamped to 0
- Values > 65535 → clamped to 65535 (warning emitted)

Examples:

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

#### Windows Compatibility

The manifest declares support for Windows 10 and Windows 11.

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

{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} GUID corresponds with these operating systems: Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 and Windows Server 2022.

More information on: Microsoft Application Manifests.

#### Long Path Awareness

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

Enables use of file paths longer than 260 characters, when supported by the operating system.

#### Execution Level

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

The default level is `asInvoker`.

To set the execution level, use the `QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL` property.

Valid values:

- `asInvoker` (default)
- `highestAvailable`
- `requireAdministrator`

Example:

     set_target_properties(myapp PROPERTIES
         QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL "requireAdministrator"
     )

If an invalid value is provided, a warning is emitted and `asInvoker` is used.

### Providing a Custom Manifest

Qt detects the manifest file and skips automatic generation, if an executable already includes a `.manifest` file in its sources:

     add_executable(myapp
         main.cpp
         myapp.manifest
     )

### Complete Example

The following example demonstrates a Windows executable using the automatically generated manifest with customized identifier and execution level:

     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 this example, the generated manifest version will be:

     2.5.1.0

### Manifest files with qmake

When deploying an application compiled with Visual Studio, there are some additional steps to be taken.

First, we need to copy the manifest file created when linking the application. This manifest file contains information about the application's dependencies on side-by-side assemblies, such as the runtime libraries.

The manifest file needs to be copied into the same folder as the application executable. You do not need to copy the manifest files for shared libraries (DLLs), since they are not used.

If the shared library has dependencies that are different from the application using it, the manifest file needs to be embedded into the DLL binary. The following `CONFIG` options are available for embedding manifests:

     embed_manifest_dll
     embed_manifest_exe

Both options are enabled by default. To remove `embed_manifest_exe`, add

     CONFIG -= embed_manifest_exe

to your .pro file.

You can find more information about manifest files and side-by-side assemblies at the Side-by-side Assemblies documentation page.

The correct way to include the runtime libraries with your application is to ensure that they are installed on the end-user's system.

To install the runtime libraries on the end-user's system, you need to include the appropriate Visual C++ Redistributable Package (VCRedist) executable with your application and ensure that it is executed when the user installs your application.

The redistributable is named `vc_redist.x64.exe` (64-bit) and can be found in the folder `<Visual Studio install path>/VC/redist/<language-code>`.

Alternatively, it can be downloaded from the web, for example https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads.

Note: The application you ship must be compiled with exactly the same compiler version against the same C runtime version. This prevents deploying errors caused by different versions of the C runtime libraries.

## Application Dependencies

### Additional Libraries

Depending on configuration, compiler specific libraries must be redistributed along with your application.

You can check which libraries your application is linking against by using the Dependency Walker tool. All you need to do is to run it like this:

     depends <application executable>

This will provide a list of the libraries that your application depends on and other information.

When looking at the release build of the Plug & Paint executable (`plugandpaint.exe`) with the `depends` tool, the tool lists the following immediate dependencies to non-system libraries:

Qt | Visual Studio 17 (2022) | Mingw-w64
--- | --- | ---

- QT6CORE.DLL - The QtCore runtime
- QT6GUI.DLL - The QtGui runtime
- QT6WIDGETS.DLL - The QtWidgets runtime

- VCCORLIB140.DLL, VCRUNTIME140D.DLL - The C runtime
- MSVCP140.DLL - The C++ runtime

- LIBWINPTHREAD-1.DLL
- LIBGCC_S_SEH-1.DLL
- LIBSTDC++-6.DLL

When looking at the plugin DLLs the exact same dependencies are listed.

### Qt Plugins

All Qt GUI applications require a plugin that implements the Qt Platform Abstraction (QPA) layer in Qt. For Windows, the name of the platform plugin is `qwindows.dll`. This file must be located within a specific subdirectory (by default, `platforms`) under your distribution directory. Alternatively, it is possible to adjust the search path Qt uses to find its plugins, as described below.

Your application may also depend on one or more Qt plugins, such as the print support plugin, the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application. Similar to the platform plugin, each type of plugin must be located within a specific subdirectory (such as `printsupport`, `imageformats` or `sqldrivers`) within your distribution directory.

The libraries are relocatable unless Qt was built with the configure switch `-relocatable` turned off. The search paths for Qt plugins are relative to the location of the QtCore library and no further steps are required to ensure plugins are found after installing the application on the target machine.

### Ensuring Plugins Are Found when Using Non-Relocatable Builds

For non-relocatable builds, additional steps must be taken to ensure plugins are found after the application has been installed on the target machine.

In this case, the search path for Qt plugins is hard-coded into the QtCore library. By default, the plugins subdirectory of the Qt installation is the first plugin search path. However, pre-determined paths like the default one have certain disadvantages. For example, they may not exist on the target machine. For that reason, you need to examine various alternatives to make sure that the Qt plugins are found:

- Using `qt.conf`. This approach is the recommended if you have executables in different places sharing the same plugins.
- Using QApplication::addLibraryPath() or QApplication::setLibraryPaths(). This approach is recommended if you only have one executable that will use the plugin.
- Using a third party installation utility to change the hard-coded paths in the QtCore library.

If you add a custom path using QApplication::addLibraryPath it could look like this:

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

Then QCoreApplication::libraryPaths() would return something like this:

- `C:/customPath/plugins`
- `C:/Qt/%VERSION%/plugins`
- `E:/myApplication/directory`

The executable will look for the plugins in these directories and the same order as the QStringList returned by QCoreApplication::libraryPaths(). The newly added path is prepended to the QCoreApplication::libraryPaths() which means that it will be searched through first. However, if you use QCoreApplication::setLibraryPaths(), you will be able to determine which paths and in which order they will be searched.

The How to Create Qt Plugins document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.