Side-by-side assembly

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, sxstrace.exe can help to diagnose failures in the starting of applications due to SxS misconfiguration.

If a user wishes to override manifest-specified assemblies (for example, in the case of security patches applied to a library), a publisher configuration file can globally redirect assemblies. Digital signatures can ensure the legitimacy of such redirection.[3]

The application 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.

<?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.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

From Vista onward, the Windows operating system uses WinSxS for its core components. Operating system files in the winsxs directory are hard linked from their usual locations in the Windows directory structure. A file in a subdirectory in winsxs may be linked from multiple locations (e.g. the System32 directory and application directories). 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]

Windows 7 includes Windows AIK tool Deployment Image Servicing and Management (DISM) which can remove files used by superseded OS updates using the Trusted Installer worker service, without the need to reboot or take down the system;[11] post-SP1 updates add Windows Update cleanup to the Disk Cleanup tool (cleanmgr.exe)[12] and the downloadable System Update Readiness tool (CheckSUR)[13] which can repair components store errors and replace corrupt or missing OS files with known good versions. Windows 8 integrates repair capability to the DISM tool which is now able to copy valid OS files from Windows Update or an offline WIM image, as well as reset the component store to only contain the latest versions of OS components.[14] Windows 10 runs the automatic task to clean up the component store.[15]

• 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.

• In Windows XP, a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service pack. Users must manually install an appropriate update.[16]
• Considerably higher apparent disk space consumption, even though most of the contents of winsxs are just additional hard links to files that exist elsewhere.
• The winsxs directory and Windows Update logs may become corrupted as they grow in size, because security updates add multiple new versions of critical system components to the store. In Windows Vista there is no supported way to significantly reduce the size of the winsxs directory.[8]

While the winsxs directory is extremely large and contains multiple versions of many files, there are some files elsewhere in the Windows folder (e.g. System32) that are hardlinks to files in the winsxs directory.[17] Thus, programs estimating the size of the Windows folder must be careful not to add the size of additional hard links to a file after one has already been counted.[18]

DIR and Explorer fail to check for hard links, and so may count the same file multiple times, adding incorrectly to the perceived disk usage. The disk usage reported by these two programs is as if each hard link is an actual file.[19]

Since Windows 8.1, the DISM tool can be used to analyze the component store and report its actual size.[20]

• Side-by-Side Assemblies (Windows)
• ClickOnce Deployment Manifest Format
• Configuring .NET-Based Components for Registration-Free Activation
• Diagnosing SideBySide failures
• Diagnose SideBySide failures in Windows XP/Windows Server 2003