What Is A. manifest file?

Well, for everyone's convenience, I will describe it as simple as possible.

[Symptom]
The Research on this problem originated from the following phenomenon: When you use VC ++ 2005 (or other. net) after writing a program, you can run the program without any problem on your computer. However, when you copy the EXE file to another computer, you cannot run the program. The general error message is as follows: the application configuration is incorrect. Please reinstall the application ...... Or msvcr80d. dll does not find anything (I do not remember it clearly, but it is roughly like this)

[Analysis]
If you see such a prompt, you won't be stupid enough to reinstall it. The first response should be about configuration problems or missing library files. Therefore, based on the previous windows lack of library files experience, I put all library files (××. DLL) Unified brain copy to the current folder, full of joy that can run, to run ...... ##￥ @#%￥ ...... Or else.

[Exploration]
So I started searching on the internet, Google, and ferry. Gradually, I found that all this was called ***. what is the relationship between manifest files. what about the manifest file? What is his use? Why not?

Later, after hard work, I finally learned that all this was originally a ghost of Windows assembly manifest. The role of this stuff is to solve the previous "DLL hell" Problem on Windows to generate a new DLL management solution. As you know, DLL dynamically loads shared libraries, and the same dll may be used by multiple programs. The so-called "DLL hell" means that when the program does not depend on the same DLL, but the version is different. Because the system cannot tell which one is, the system loads the wrong dll version and then fails. As a result, Gates learned the lesson and developed an assembly list. Each program must have a list, which is stored in the same name as its own application. in the manifest file, it lists all the Dependencies it requires. The dependencies listed here are not simply distinguished by the file name, it is differentiated by something called a "strong File Name". What is a strong file name? Let's take a look at this. manifest file.

<? XML version = '1. 0' encoding = 'utf-8' standalone = 'Yes'?> <Assembly xmlns = 'urn: Schemas-Microsoft-com: ASM. V1 'manifestversion = '1. 0'> <Dependency> <Dependentassembly> <Assemblyidentity type = 'win32 'name = 'Microsoft. vc80.crt' version = '8. 0.50608.0 'processorarchitecture = 'x86' publickeytoken = '1fc8b3b9a1e18e3b '/> </Dependentassembly> </Dependency> </Assembly>

We found that this is an XML file. The <dependency> part indicates that it depends on a library named Microsoft. vc80.crt. However, we found that there are other things in the <assemblyidentity> attribute, which are
Type system type, version number, processorarchitecture platform environment, publickeytoken Public Key (usually used to mark a company )...... Adding them together becomes a "strong File Name". With this "strong file name", we can differentiate different versions and platforms according to them ...... In short, with such a strong file name, the system can have multiple different versions of the same library coexist without conflict.

[In-depth]

Well, now let's take a look at this mechanism.
The first is the issue of strong and weak file names. As mentioned above, to distinguish the same Assembly generated by different versions or different vendors, you must use an assembly manifest program list to list the strong file names of my assembly, at this point, you may ask: I didn't mean that the assembly manifest program list is a strong file name for the Assembly on which it depends. Why is it clear that the current file is a strong file? In fact, the assembly manifest program list has two functions. The above example indicates the strong File Name of the dependent file because it is the assembly manifest of the client, there is another manifest to mark on the server.

<? XML version = "1.0" encoding = "UTF-8" standalone = "yes"?> <Assembly xmlns = "urn: Schemas-Microsoft-com: ASM. V1" manifestversion = "1.0"> <Noinheritable> </noinheritable> <Assemblyidentity type = "Win32" name = "Microsoft. vc80.crt" version = "8.0.50727.42" processorarchitecture = "x86" publickeytoken = "1fc8b3b9a1e18e3b"> </assemblyidentity> <File name = "msvcr80.dll" hash = "comment" hashalg = "sha1"> <asmv2: Hash xmlns: asmv2 = "urn: Schemas-Microsoft-com: ASM. v2 "xmlns: dsig =" http://www.w3.org/2000/09/xmldsig# "> <dsig: Transforms> <dsig: Transform Algorithm =" urn: Schemas-Microsoft-com: hashtransforms. identity "> </dsig: Transform> </dsig: Transforms> <dsig: digestmethod algorithm =" http://www.w3.org/2000/09/xmldsig#sha1 "> </dsig: digestmethod> <dsig: digestvalue> phruexlaez8bwmld8vlo5udanre = </dsig: digestvalue> </asmv2: Hash> </File> <File name = "msvcp80.dll" hash = "comment" hashalg = "sha1"> <asmv2: Hash xmlns: asmv2 = "urn: Schemas-Microsoft-com: ASM. v2 "xmlns: dsig =" http://www.w3.org/2000/09/xmldsig# "> <dsig: Transforms> <dsig: Transform Algorithm =" urn: Schemas-Microsoft-com: hashtransforms. identity "> </dsig: Transform> </dsig: Transforms> <dsig: digestmethod algorithm =" http://www.w3.org/2000/09/xmldsig#sha1 "> </dsig: digestmethod> <dsig: digestvalue> 7ay1jqouvk3u/6 bywboagggafbc = </dsig: digestvalue> </asmv2: Hash> </File> <File name = "msvcm80.dll" hash = "comment" hashalg = "sha1"> <asmv2: Hash xmlns: asmv2 = "urn: Schemas-Microsoft-com: ASM. v2 "xmlns: dsig =" http://www.w3.org/2000/09/xmldsig# "> <dsig: Transforms> <dsig: Transform Algorithm =" urn: Schemas-Microsoft-com: hashtransforms. identity "> </dsig: Transform> </dsig: Transforms> <dsig: digestmethod algorithm =" http://www.w3.org/2000/09/xmldsig#sha1 "> </dsig: digestmethod> <dsig: digestvalue> hwq8zaztsmekvxwfba6bnv4heow = </dsig: digestvalue> </asmv2: Hash> </File> </Assembly>

This is a manifest file obtained from the Windows/winsxs/manifests directory. in this folder, there is a manifest file in XML format, which is a list of programs on the server. Winsxs is a [Blue] unmanaged parallel cache (side-by-side catche) [/Blue] provided by Windows XP and later versions. It has installed various versions of the system library with strong file name signatures, the above file <assemblyidentity> indicates Microsoft in the system. A vc80.crt version has a strong file name signature .. The dependency pairs listed in <dependentassembly> in the manifest list are loaded. The side-by-side mentioned above refers to the parallel running of different versions.
The <File> tag in the above server manifest file specifies which file is signed by the strong file name, And the hash signature of the file is included to ensure file integrity.

Well, with this mechanism, we can perform database file association very securely, but it seems that there is still a problem that has been plaguing us: this mechanism is safe, however, it loses the good compatibility between the previous versions and earlier versions. That is, if your system library is upgraded, the version number of the server has changed. Isn't all the server programs unavailable? In fact, windows also uses a policy file to confirm the ing relationship.

<? XML version = "1.0" encoding = "UTF-8" standalone = "yes"?> <! -- Copyright? 1981-2001 Microsoft Corporation --> <Assembly xmlns = "urn: Schemas-Microsoft-com: ASM. V1" manifestversion = "1.0"> <Assemblyidentity type = "win32-policy" name = "yy.8.0.microsoft. vc80.crt" version = "8.0.50727.42" processorarchitecture = "x86" publickeytoken = "1fc8b3b9a1e18e3b"/> <Dependency> <Dependentassembly> <Assemblyidentity type = "Win32" name = "Microsoft. vc80.crt" processorarchitecture = "x86" publickeytoken = "1fc8b3b9a1e18e3b"/> <Bindingredirect oldversion = "8.0.41204.256-8.0.50608.0" newversion = "8.0.50727.42"/> </Dependentassembly> </Dependency> </Assembly>

This is a policy file in the Windows/winsxs/policies directory, the <bindingredirect> label specifies all the customer requirements for 8.0.41204.256-8.0.50608.0 to be mapped to 8.0.50727.42, which is the newer version library installed in my current system. Of course, we can also map other fields, which can effectively solve the problems caused by system upgrades.

[Application]
After the above explanation, everyone has a general understanding of the entire dependency search process, so the problem can be solved in practice.
Let's go back to the actual problem. As I said before, after compiling a program and connecting it to an executable program, I found that the dependent library could not be found on other people's computers, so what should we do? If you are smart, you naturally want to copy the corresponding version of the Library to the target computer, ...... When you are desperately searching for the Assembly manifests file of the executable file, you suddenly find that the file cannot be found. There is only one EXE file in the execution directory. Is it not generated? Obviously not. It turns out that the resource connector connected the Assembly manifests file to the executable file. If you don't believe it, you can use your VC ++ to open an executable file, there is a project named rt_manifest in its resource items. This is a binary manifests file. Copy the dependent files (usually the CRT Runtime Library) of the corresponding version to the system directory Windows/winsxs /, remember that it will be copied to that folder together with a special named directory, for example, the CRT Runtime Library is winsxs/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50608.0_x-ww_b7acac55 has such a directory, it indicates the version number, signature, and other information of the database to prevent duplicate versions from being copied to the same winsxs directory.

Is that done? If everything was solved before, the system will find the Runtime Library under this directory, but this is not the case now, but the system will find the Assembly manifests file of this Runtime library, it can only be loaded after a strong comparison of file names, so do not forget to copy the corresponding manifests file to the/winsxs/manifests directory.

Of course, in this way, the target system folder is moved to the dago, which is naturally too violent. Fortunately, windows also provides us with a private search method. In this way, you can find the appropriate library in the local folder before finding it. So you just need to copy the previous library and the manifests file together to the path of your application.

According to the msdn instructions, follow the following rules to search and load locally:

Find the configuration file <assemblyname>. manifest in the local application folder. In this example, the loader tries to find Microsoft. vc80.crt. manifest in the folder where appl.exe is located. If this list is found, the loader loads the crt dll from the application folder. If no crt dll is found, loading will fail. Open the <assemblyname> folder in the local appl.exe folder. If this folder exists, load the <assemblyname>. manifest file from it. If this list is found, the loader loads the crt dll from the <assemblyname> folder. If no crt dll is found, loading will fail.

Finally, I want to add that under the "Microsoft Visual Studio 8/VC/redist" directory under your VC ++ installation directory, all provided and released products are provided accordingly. the library file of the manifest. So you want to publish a program in the simplest and safest way (Don't worry about whether your computer contains the library you need) the folder of the corresponding library under this directory is put together with your executable file for release.
For example, if you use the CRT library for your executable files on the X86 platform, copy Microsoft Visual Studio 8/VC/redist/x86/Microsoft. the vc80.crt folder is in the directory where your program is located. If it is released together, everything will be fine!