Difference between revisions of "Manifest file"
(→The dependency element: Elaborate) |
m (spelling) |
||
| Line 1: | Line 1: | ||
A Visual Prolog project can contain a '''manifest''' file. The manifest file is a Microsoft invention to deal with side-by-side installation, a new hell that is supposed to replace the so called [[wikipedia:DLL hell|DLL hell]]. | A Visual Prolog project can contain a '''manifest''' file. The manifest file is a Microsoft invention to deal with side-by-side installation, a new hell that is supposed to replace the so called [[wikipedia:DLL hell|DLL hell]]. | ||
The file is either named '''<project>.manifest''' or '''main.manifest''' ( | The file is either named '''<project>.manifest''' or '''main.manifest''' (vip 7.3 standard). | ||
The manifest file is an XML file, and it is linked into EXE/DLL as a resource. Windows automatically look for it there (if not found there it looks for a file called '''myProgram.exe.manifest''' in the same directory as '''myProgram.exe'''). | The manifest file is an XML file, and it is linked into the EXE/DLL as a resource. Windows automatically look for it there (if not found there it looks for a file called '''myProgram.exe.manifest''' in the same directory as '''myProgram.exe'''). | ||
=== Sample manifest file === | === Sample manifest file === | ||
Latest revision as of 01:14, 26 February 2010
A Visual Prolog project can contain a manifest file. The manifest file is a Microsoft invention to deal with side-by-side installation, a new hell that is supposed to replace the so called DLL hell.
The file is either named <project>.manifest or main.manifest (vip 7.3 standard).
The manifest file is an XML file, and it is linked into the EXE/DLL as a resource. Windows automatically look for it there (if not found there it looks for a file called myProgram.exe.manifest in the same directory as myProgram.exe).
Sample manifest file
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity name="MyProgram" version="1.0.0.0" processorArchitecture="X86" type="win32" /> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" type="win32" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly>
The file contains three major elements:
- The programs own assemblyIdentity
- A trustInfo element
- A dependency, which lists assemblyIdentity's of assemplies that the program depends on.
The assemblyIdentity element
<assemblyIdentity name="MyProgram" version="1.0.0.0" processorArchitecture="X86" type="win32" />
This element list attributes of the program/DLL itself.
The trustInfo element
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo>
The level can have one of these values:
- asInvoker
- The application runs with the same access token as the parent process.
- Recommended for standard user applications. Do refractoring with internal elevation points, as per the guidance provided earlier in this document.
- highestAvailable
- The application runs with the highest privileges the current user can obtain.
- Recommended for mixed-mode applications. Plan to refractor the application in a future release.
- requireAdministrator
- The application runs only for administrators and requires that the application be launched with the full access token of an administrator.
- Recommended for administrator only applications. Internal elevation points are not needed. The application is already running elevated.
Notice programs which don't have a manifest with a requestedExecutionLevel element, will run virtualized on Windows Vista and forward. As an example of what this means: A virtualized program cannot write to the HKEY_LOCAL_MACHINE hive of the registry, instead it writes to a virtual overlay of this hive. However only virtualized programs for the same user see this overlay. So other users cannot see this overlay, and non-virtualized programs does not see it either.
The dependency element
<dependency> <dependentAssembly> <assemblyIdentity name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" type="win32" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency>
The dependency element list other assemblies that this assembly depends on.
With the "Microsoft.Windows.Common-Controls" entry listed above your program will use version 6.0 of the Windows Shell Common Controls on machines that have this assembly installed. This is the way to use the theme aware version of the common controls (which by default are flat-bended with rounded corners; light blue selection and yellow hover glow).