In the early days Microsoft recommend installing DLLs to c:\windows\system32 if you wanted to share them with other applications. This lead to “DLL Hell” since one applications installer would install one version of a DLL and another installer would install another version overwriting the existing DLL. If the new version of the DLL wasn’t compatible the older application would suddenly break and stop working. With SxS technology, applications can install DLLs to version specific directories tell Windows what version of the DLL should be used when they load a DLL by that name.
You can refer this article to get the basics of Assemblies
Windows OSes which have SxS will look for an application’s manifest information to determine which version to load from SxS. A manifest is a fairly simple XML description of all the SxS DLLs that might be loaded by the application and which version to use. The manifest can either be embedded in the application EXE/DLL file as a resource or stored separately on the filesystem as a .manifest file. In the second case, the manifest file for app.exe would be called app.exe.manifest.
The manifest resolution algorithm is fairly complex and I won’t get into all the details here, but it can include among other things searching based on the user’s locale (i.e. Look for French/German version first). As well, to eliminate security disasters like what happened with gdiplus.dll, SxS DLLs have a “force upgrade” mechanism implemented as separate security policy files (also XML files). This mechanism allows Microsoft to override version number request by applications in the case where some gaping security hole is discovered in a shared library that effects thousands of applications. For example, an application manifest may say “I want version 18.104.22.168 of xyz.dll”, but Microsoft can push a policy file update that says “redirect all request of version 22.214.171.124 to 126.96.36.199”.