Overview¶

This following information applies to Microsoft Windows only.

A manifest is some XML (typically embedded into .dll and .exe files) which can (among other things) specify the exact version of the Microsoft Visual C++ runtime (MSVCRT) that an application requires. In theory this information allows Windows to check basic requirements of an application early (and possibly avoid application crashes).

For .exe files compiled with MSVC8 and MSVC9 a manifest specifying the MSVCRT is generally mandatory. (With MSVC10, Microsoft once again removed the requirement for a manifest.)

For .dll files a manifest is mandatory only if the .exe file of the process loading a specific .dll does not specify any MSVCRT or an MSVCRT of a different major version number.

External manifests¶

Manifests do not necessarily need to be embedded into binary files (such as .dll and .exe files), but can be located in the file system too. File system manifests must be called _executable_name_``.manifest.

For example, for an application whose executable is C:\My App\MyApp.exe, the manifest file name must be C:\My App\MyApp.exe.manifest.

Note however, that when an external and an embedded manifest exist at the same time, different versions (or even patch levels?) of Windows may prefer one over the other, or vice versa, so you cannot reliably know which one will be preferred. For this reason it is good practice to have only internal or only external manifests.

Viewing manifests¶

Manifests can be viewed by using the manifest tool ( mt.exe ). For example:

mt.exe "-inputresource:C:\Windows\system32\notepad.exe" "-out:temp.txt"
notepad temp.txt

It is also possible to specify the index position at which to look for the manifest. (The standard index for .exe manifests is 1 and for .dll manifests is 2):

mt.exe "-inputresource:C:\Windows\system32\notepad.exe;1" "-out:temp.txt"
notepad temp.txt

Setting manifests¶

The manifest tool can also be used to set a manifest:

mt.exe -manifest "C:\mymanifest.txt" "-outputresource:C:\My App\MyApp.exe;1"

It is possible that mt.exe will fail to set a manifest. In such cases you can try to remove any existing manifest first, (e.g., using the third-party Anolis Resourcer tool), and then try again with mt.exe.

Removing manifests¶

The Anolis Resourcer tool can remove embedded manifests.

Open the file and select its manifest:

Click Action→Delete Resource (the context menu's delete option may not work):

Third party tools for manifest handling¶

There are other tools that can be used to view, edit, set, and remove the manifests in .exe and .dll files.

Visual Studio¶

For example you can open .exe and .dll files in Visual Studio and edit their manifest (use File→Open).

Anolis Resourcer¶

Another tool that can be used for this is Anolis Resourcer .

Note that sometimes the Resourcer tool is not able to edit a manifest directly, but it may still be able to remove a manifest and then set a new manifest.

Manifest example¶

Here is a manifest for a .exe file that specifies that the MS Visual C++ runtime version 9.0.21022.8 or higher is required:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Manifests in Squish .dlls¶

Squish binary packages provided by froglogic do not have manifests in .dll files whenever possible because this avoids the majority of the problematic configurations, especially with Squish for Qt.

A configuration is problematic when a version discrepancy exists between the MSVCRT version specified in the .exe file, the Squish .dlls and other .dlls loaded by the AUT.

The only way to avoid manifest-related problems is to either have no manifests in .dll files if at all possible, or to have the manifests of all the .dll files specify exactly the same version of their respective MSVCRT runtime.

Example #1 - no manifests in Squish .dlls

Example #2 - manifests in Squish .dlls

As you can see all the binaries compiled with MSVC9 which have a manifest specify the exact same version of the MSVC9 CRT in their manifest.

Manifest-related problems with Squish¶

Squish may load one or more of its own libraries into the process of the AUT at runtime.

Whether this works successfully or not can depend on which compiler was used to compile Squish's .exe and .dll files; whether the Squish .dlls contain a manifest; and whether the MSVCRT version numbers specified in the manifests of the Squish .dlls are higher or lower than the MSVCRT version specified in the AUT's .exe file.

See the table of configurations below ( Compiler/Manifest configuration matrix ).

Compiler/Manifest configuration matrix¶

Legend

Squish .dlls - stands for the Squish .dlls which are loaded into the AUT process at runtime.

None - stands for "No manifests that specify an MSVCRT requirement/dependency".

• compile
• Windows