Side-by-side assembly: Difference between revisions
| Line 46: | Line 46: | ||
* Thus far, Windows XP and later versions are the only operating systems to implement SxS, so none of the advantages of SxS are portable to older versions of Windows. |
* Thus far, Windows XP and later versions are the only operating systems to implement SxS, so none of the advantages of SxS are portable to older versions of Windows. |
||
* More data storage is consumed by this process. Anyway the real size is usually |
* More data storage is consumed by this process. Anyway the real size is usually smaller than reported as [[hardlink|hardlinks]] are used . |
||
== See also == |
== See also == |
||
Revision as of 10:17, 13 March 2010
Side-by-side technology is a standard for executable files in Microsoft Windows XP and later versions that attempts to reduce DLL hell. Side-by-side technology is also known as WinSxS or SxS. Executables that include an SxS manifest are designated SxS assemblies.
DLL hell designates a group of problems that arise from the use of dynamic-link libraries in Microsoft Windows. Problems include version conflicts, missing DLLs, duplicate DLLs, and incorrect or missing registration. In SxS, Windows stores multiple versions of a DLL in the WinSXS subdirectory of the Windows directory, and loads them on demand. This reduces dependency problems for applications that include an SxS manifest.
Microsoft Visual C++ 2005 and later employ SxS with all C runtime libraries.
Operation
An application that employs SxS must have a manifest. Manifests are typically a section embedded in the application's executable file but may also be an external file. When the operating system loads the application and detects the presence of a manifest, the operating system DLL loader is directed to the version of the DLL corresponding to that listed in the manifest. If there is no manifest, the DLL loader loads a default version of all DLL dependencies.
Manifest format
The manifest is internally represented as XML. The URN associated with SxS manifests is "urn:schemas-microsoft-com:asm.v1".
Several other recent Microsoft technologies such as ClickOnce employ the same manifest format.
Example manifest
The following is an example of a manifest for an application that depends on a C runtime DLL.
<?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' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
Advantages
- For applications that have been built with SxS, multiple applications may coexist that depend on different versions of the same DLL. This is in contrast to non-SxS DLL environments where an original DLL in a shared system folder may be overwritten by the subsequent installation of another program that depends on a different version of the same DLL.
- The XML formatting of the manifest is human-legible and thus makes it easier for developers to determine the dependencies of an application and their versions.
Disadvantages
- The benefits of SxS are not completely retroactive; that is, DLL hell may still occur for applications with no manifest or for applications that do not follow the SxS DLL installation strategy.
- Thus far, Windows XP and later versions are the only operating systems to implement SxS, so none of the advantages of SxS are portable to older versions of Windows.
- More data storage is consumed by this process. Anyway the real size is usually smaller than reported as hardlinks are used .