Using the manifest file to classify DLLs under the program directory

1 background

For most brokers and institutional investors, spot trading can only be done through a counter system provided by brokers with access to the exchange trading system. Compared with the futures market, the spot market's counter system is very diverse, the access Protocol has plaintext strings, binary data and fix protocol, such as access to TCP connections, COM components and DLL dynamic library. To develop an offer system that covers all the spot counters on the market, you must be able to support all access methods at the same time. The following are some of the issues encountered in the development process regarding the version compatibility of dynamic libraries:

1. The same counter system provider has released 2 counter systems for docking the development kits for these 2 systems, just as the versions are not universal
2. Dynamic libraries provided by different counter systems contain different versions of third-party library files (such as Libeay32.dll, etc.)
3. Some brokers have custom developed the counter system, adding their own dynamic libraries to the development packages provided by the counter to increase control over access authorization.

When there is a different version of the dynamic library with the same name in the system, these dynamic libraries can only be sorted to make it easy to manage and update the program. The practice is to set up a separate folder for each category in the program execution directory to hold all the dynamic library files needed to connect to the counter. Because the program uses static loading to load the DLL, the manifest file is used in order for the executable file to be able to find these dynamic libraries at startup.

2 About manifest file

manifest files are XML files that are used to organize and describe parallel components or standalone applications. It primarily contains information about binding and activating COM classes, interfaces, and libraries, which were previously stored in the system registry [1]. in XP and later Windows systems, the system executes the EXE executable file will first read the manifest file, the exe file needs to call the list of DLLs (obtained at this time, not directly the DLL file itself location, Instead of the DLL's manifest), the operating system then finds the corresponding DLL based on the information provided by the DLL's manifest file, so that it can distinguish between different versions of the DLL file of the same file name [2].

A mapping on Microsoft MSDN visually describes this process [3]:

3 Component Lookup Order

In a Windows system, if the application specifies a component dependency, the program starts by locating the shared component in the WinSxS folder, and if it is not found, looks for the private component under the program installation directory.

In most cases, the lookup order of the components is as follows:

1. WinSxS folder
2. \\<appdir>\<assemblyname>. Dll
3. \\<appdir>\<assemblyname>.manifest
4. \\<appdir>\<assemblyname>\<assemblyname>. Dll
5. \\<appdir>\<assemblyname>\<assemblyname>.manifest

For a more detailed description, you can view the assembly searching in MSDN Sequence

4 implementation

Scenario a program needs to load two different versions of Sample.dll

Workaround:

2. Set up two folders (DLLA,DLLB) and put two different versions of DLLs into the two folders respectively
4. Folder to create a new manifest file, file name with folder name, example Dlla.manifest, dllb.manifest
5. edit the manifest file as follows (take Dlla as an example):

   1 <Assemblyxmlns= "Urn:schemas-microsoft-com:asm.v1"manifestversion= "1.0">2   <assemblyidentityname= "dlla"processorarchitecture= "x86"version= "1.0.0.0"type= "Win32" />  <-- This name must be the name of the folder where the manifest file is located .3 <file name= "sample.dll"/> 4 </Assembly>

6. Add the following preprocessing directives in the CPP that need to use the functions provided by the dynamic library (take Dlla as an example):

   1 //Specifies the location where the DLL is loaded;2 #pragmaComment (linker, "/manifestdependency:\" Type= ' Win32 ' "3     "name= 'dlla'"4     "version= ' 1.0.0.0 '"5     "processorarchitecture= ' x86 '"6     "language= ' * '"7     "\"")

Once recompiled, the program can correctly locate the specified dynamic library.

Scenario two programs need to load two different versions of Sample.dll, and different versions of Sample.dll rely on different third-party development libraries, respectively

Workaround: On the basis of scenario one solution, add dependent third-party library information in the manifest file, for example:

1 <Assemblyxmlns= "Urn:schemas-microsoft-com:asm.v1"manifestversion= "1.0">2 3   <assemblyidentityname= "Dlla"processorarchitecture= "x86"version= "1.0.0.0"type= "Win32" />4 5   <filename= "Sample.dll"/>6   <filename= "Libeay32.dll"/>7   <filename= "Ssleay32.dll"/>8     9 </Assembly>

Scenario three programs need to load two different versions of Sample.dll, but the code that calls these 2 dynamic libraries has some kind of referential relationship.

Workaround: In this scenario, because the precompiled macros are overwritten with each other, the dynamic library does not load correctly, and can only be dynamically loaded by means of LoadLibrary. In fact, dynamic loading can load any path of the dynamic library, but it is not easy to use the static loading mode.

4 Summary

Using the manifest file to load multiple versions of a dynamic library with the same name at the same time is a feature that is unique to Windows, and rarely comes into contact with the usual C + + development. This is for reference only when a record is used for subsequent encounters of the same problem.

1. https://msdn.microsoft.com/en-us/library/aa375365 (v=vs.85). aspx
2. http://blog.csdn.net/suxinpingtao51/article/details/42870937
3. https://msdn.microsoft.com/en-us/library/ff951640 (v=vs.85). aspx

This article is original content, if there is wrong place please correct me

This address: http://www.cnblogs.com/morebread/p/4953497.html

Using the manifest file to classify DLLs under the program directory