0

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

starblue
  • 55,348
  • 14
  • 97
  • 151
Alex
  • 5,477
  • 2
  • 36
  • 56

2 Answers2

4

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.

Chris Becke
  • 34,244
  • 12
  • 79
  • 148
  • Can you explain how one can archieve item 3? Is manual using of activation context API the only way? I do not see a way to store two versions of DLL as private assembly. – Alex Jan 23 '11 at 22:07
  • 1
    You can't store two versionf of a dll as a private assembly in the same location. The activation context api however lets you provide the assembly search folder. – Chris Becke Jan 24 '11 at 05:14
  • *"...a complicated way of making things fail more often..."* - Citation, please. – jww Jun 15 '19 at 21:16
1

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • So, how assembly is different from a usual DLL? I can put DLL in app's folder too. Why do I need a manifest for that? – Alex Jan 23 '11 at 18:21
  • Not sure what you are asking. You need a manifest when the DLL is a COM server. Other DLLs (native and managed) are simply found because Windows and the CLR always look in the directory where the EXE came from. The (horrible) side-by-side docs use the term 'assembly' as a generic term, means DLL in practice. – Hans Passant Jan 23 '11 at 18:28
  • I'm talking about this ( http://msdn.microsoft.com/en-us/library/ff951638(VS.85).aspx ): "Private assemblies **must** be accompanied by an assembly manifest". – Alex Jan 23 '11 at 22:03
  • Yes, those are the *horrible* docs I mentioned, studied them thoroughly and only ever got it to work by trial and error. The Microsoft programmer that's behind all this is Junfeng Zhang. He's had a blog, you pretty much have to read all of his posts to get half a clue what the MSDN docs really mean. Only the .NET behavior (aka fusion) is well documented, the native behavior is subtly and inscrutably different. c:\windows\winsxs is a good idea, but nobody other than Microsoft uses it because nobody has figured out yet how. A different kind of DLL Hell. – Hans Passant Jan 23 '11 at 22:36