An assembly’s manifest file typically has a name that includes the name of the assembly,
version information, some text that represents a unique signature, and the extension “.manifest”.
The manifests are stored in \Windows\Winsxs\Manifests, and the rest of the assembly’s resources
are stored in subdirectories of \Windows\Winsxs that have the same name as the corresponding
manifest files, with the exception of the trailing .manifest extension.
An example of a shared assembly is version 6 of the Windows common controls DLL,
comctl32.dll. Its manifest file is named \Windows\Winsxs\Manifests\x86_Microsoft.Windows.
Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.manifest. It has an associated
catalog file (which is the same name with the .cat extension) and a subdirectory of Winsxs that
includes comctl32.dll.
Version 6 of Comctl32.dll added integration with Windows themes, and because applications
not written with theme support in mind might not appear correctly with the new DLL, it’s
available only to applications that explicitly reference the shared assembly containing it—the
version of Comctl32.dll installed in \Windows\System32 is an instance of version 5.x, which is
not theme aware. When an application loads, the loader looks for the application’s manifest, and if
one exists, loads the DLLs from the assemblies specified. DLLs not included in assemblies
referenced in the manifest are loaded in the traditional way. Legacy applications, therefore, link
against the version in \Windows\System32, whereas theme-aware applications can specify the new
version in their manifest.