Side-by-side assembly

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jotbee (talk | contribs) at 10:34, 9 May 2012 (fix duplicate reference). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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, although technically WinSxS refers only to the global side-by-side store (officially called the "Windows component store"), which is conceptually the native equivalent of the .NET Global Assembly Cache. 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 2008 employ SxS with all C runtime libraries. However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now.[1][2]

SxS is also the technological basis for registration-free COM activation. Only in-process COM servers may be activated this way.

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. If the DLL is a COM server, it must have a manifest of its own for registration-free activation to succeed.

On Windows Vista and later, application start failures due to SxS misconfiguration can be diagnosed using sxstrace.exe.

Because it is sometimes desirable to override manifest-specified assemblies anyway, for example in the case of security patches applied to a library, a publisher configuration file can globally redirect assemblies. Digital signatures may be used to ensure that this redirection is legitimate.[3]

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>

Activation Contexts

A manifest like the one above is parsed into an Activation Context by the SxS loader. There is a stack of Activation Contexts for each thread or fiber. An API allows programmatic manipulation of these contexts. It may be necessary for a library (DLL) to change its activation context, for example if it requires a specific version of another library for its own consumption instead of using the Activation Context of its caller. This type of issue is sometimes called (activation context) pollution.[4] To prevent polluting its activation context, a DLL can have a manifest embedded as a resource, which is parsed when the DLL is loaded. This manifest must be at resource id 2 in the image file for the loader to find it.[5]

WinSxS

From Vista onward the operating system also uses WinSxS for its core components. Operating system files in the WinSxS directory are hard linked to their usual locations in the Windows directory structure. The same file may be linked from a directory in WinSxS and from, say, the System32 directory. Windows Explorer double counts the disk space occupied by these files.[6] This can be demonstrated using the fsutil command-line program.[7] (Some third-party Explorer extensions to show the link count also exist.) However not all files from WinSxS are projected this way to "live" operating system files. For example, after installing some Windows updates, old file versions replaced by the updates are still kept in WinSxS although they are no longer linked in the "live" Windows directories. This allows updates to be uninstalled safely.[8]

Because of its elevated importance, from Vista onward the WinSxS directory is owned by the Trusted Installer service SID. By default not even administrators can modify its contents (without taking ownership first). Uninstalling applications does not immediately free space in the WinSxS directory; space for unused assemblies is garbage-collected over time by the Installer service.[9]

Although not officially documented, the algorithm for generating the directory names residing inside the WinSxS directory has been made public on an MSDN Microsoft employee's blog. The algorithm was changed in the transition from XP to Vista.[10]

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

  • Only supported on Windows XP and later. In Windows XP, a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering).[11]
  • Considerably higher disk space consumption. The winsxs directory typically starts at several gigabytes in size and continues to grow as applications are installed. Further, there is currently no way to significantly reduce the size of the winsxs directory.[8]

See also

Notes

  1. ^ Section "Visual C++ Libraries" in Breaking Changes in Visual C++. Retrieved on 2010-09-10.
  2. ^ See section "Differences between Visual C++ 2008 and Visual C++ 2010" in "Deployment in Visual C++ 2010". Retrieved on 2010-09-10.
  3. ^ http://msdn.microsoft.com/en-us/library/Aa375680
  4. ^ http://blogs.msdn.com/b/jonwis/archive/2006/01/07/510375.aspx
  5. ^ http://blogs.msdn.com/b/jonwis/archive/2006/01/17/514192.aspx
  6. ^ http://support.microsoft.com/kb/2592038
  7. ^ http://blogs.technet.com/b/joscon/archive/2010/08/06/should-you-delete-files-in-the-winsxs-directory-and-what-s-the-deal-with-vss.aspx
  8. ^ a b Huges, Jeff. "What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large?". Microsoft Corporation. Retrieved 15 March 2011.
  9. ^ http://blogs.msdn.com/b/jonwis/archive/2007/01/02/deleting-from-the-winsxs-directory.aspx
  10. ^ http://blogs.msdn.com/b/jonwis/archive/2005/12/28/507863.aspx
  11. ^ http://support.microsoft.com/kb/943232

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=Side-by-side_assembly&oldid=491565286"