- Table of Contents
- Cause #1 - Application is statically linked to Qt
- Cause #2 - Different compiler used for Qt and Squish
- Cause #3 - Different build type used for application and Squish
- Cause #4 - Stray MSVC runtime DLL files
- Cause #5 - Application .exe not linking against respective MSVC runtime
You are getting the following error in Runner/Server Log or as a separate dialog:
Use a dynamically linked application.
Use the same compiler for the application and for Squish, or use a correctly matching Squish binary package.
Use the same build type for application and for Squish, or, with Squish binary packages, use a release build of the application. (Binary packages provided by froglogic are release builds unless otherwise stated.)
Remember that the compiler, Qt, Squish, and AUT build types (and Qt versions) must all match up. If one is built as a debug type, they must all be.
The Squish binary packages are not compatible with debug builds of the AUT. Please use a release build of your AUT for testing or build Squish from a source package (you need to specify the option --enable-debug for Squish's configure program).
MinGW compiles applications of debug type by default.
One or more of the following files is...
- in the working directory of the application,
- in one of the directories listed in the PATH environment variable, or
- in <SQUISH_DIR>\bin or <SQUISH_DIR>\lib:
|Possibly stray MS Visual C++ runtime files|
Please note that in order not to be considered "stray" files, a file such as Microsoft.VC80.CRT.manifest or Microsoft.VC90.CRT.manifest must exist in the same folder as the above files.
Remove or rename these files, or move them out of the PATH.
Please note: This should be safe to do because these files (without the above mentioned manifest file) present an invalid configuration as far as Microsoft/Windows are concerned.
Using the Visual C/C++ compilers it is possible (by not using the /MD compiler/linker switch) to link .exe files without directly linking against the respective MS Visual C++ runtime.
Here is an example of a .exe file compiled with MSVC9, but not linking directly against the MSVC9 runtime, shown in Dependency Walker:
The problem arises when the application tries to load a DLL which requires that or another version of the MS Visual C++ runtime, but which does not specify this in its manifest (or which simply does not have a manifest).