Private side-by-side assembly in 1 DLL - is it the same as usual DLL?

I'm looking at Side-by-Side assemblies and isolated application solution in Microsoft Windows.

Documentation says:

A private assembly is an assembly that is deployed with an application and is available for the exclusive use of that application.

and

Private assemblies must be designed to work side-by-side with other versions of the assembly on the system.

However, the deployment process for private assembly is just copying assebly into application's folder (or subfolder with assembly's name). Thus, application can not use more than one version of private开发者_JAVA百科 assembly. Because if you put another version of private assembly - it'll overwrite old version.

Can someone explain this to me?

If this is indeed so - then what are advantages of such assemblies over usual DLLs with redirection? They seems pretty the same to me and manifest seems not even be used here.

Using private SxS assemblies to deploy dlls is really just a complicated way of making things fail more often.

There are some advantages however:

• SxS assemblies are more secure, in that only the WinSxS folder, and the EXE's folder will be searched.
• SxS assemblies are necessary for registration free COM. Which means you can deploy an app with a COM object bundled as a SxS assembly, that can be installed via XCopy and no elevation.
• SxS assemblies start to become more powerful when you realize that you CAN use the technology to load multiple different versions of the same Dll even when installed as a private SxS assembly. In the normal course of events, when the Windows Loader loads your EXE file and processes its manifest to create the activation context it uses the application folder as the base folder for SxS searching.

However, you can create your own activation contexts at runtime using the Activation Context API with base folders you specify, that will then be searched for private SxS assemblies. You can use this technique to dynamically load optional assemblies, or different versions of assemblies to implement some kind of plugin api if necessary.

To use the Activation Context API you need to:

• Realize that this cannot be used for statically bound resources as those are always loaded in a context generated by the OS loader.

• create some application manifest files describing the dependent assemblies you want to optionally load that you ship with your application - externally, or embedded as RT_MANIFEST resources with resource IDs > 16.

• Populate an ACTCTX structure with the details of where the manifest is located, and ensure that lpAssemblyDirectory points to a directory holding a specific version of a private SxS assembly. Call CreateActCtx to create an activation context object.

• When it comes time to load a specific version of the dll, activate the appropriate activation context using ActivateActCtx, then call LoadLibrary on the simple name of the dll. Deactivate it after the call as, with the dll loaded, the activation context is no longer required to be active - until & unless you make another call to an API function that will need to search the activation context - e.g. create a window of a class hosted in the dll, or create a registration free com object.

The system will - while loading the dll - search the provided lpAssemblyDirectory for the dll AND any dependent assemblies it may have.

Well, each EXE will have its own private DLL. No overwriting here, you'd put each EXE in its own install directory. They can have different versions of the DLL by design, DLL Hell is non-existent. Other than that those DLLs might touch other parts of the file system or the registry and step on each other toes doing that. The reference to "must be designed to work side-by-side". This is rarely hard to achieve.