Private Assembly Library
|how-to | home|
Private assemblies can only be used by one application. They are copied to a subdirectory of that application and, effectively, become a part of that application. Application installation only requires a copy operation. No component registration is required.
The disadvantage of using private assemblies is that they have to be copied into every application that uses it. This results in increased disk space requirements on the target machine - the same private assembly is copied to disk multiple times - and in memory requirements - the same DLL loaded from different locations is seen by Windows as a different module and is allocated separate physical memory.
Note: When Windows loads the same physical module (DLL) into multiple address spaces (processes) it allocates the same physical memory (RAM) to multiple processes. It then maps different virtual addresses (from each process) to the same physical address. This reduces RAM requirements when DLLs are used by many processes. To prevent processes from changing each other's memory, this common area is marked copy on write (see Copy-on-Write Protection).
It is a matter of analysis and individual decision on whether shared or private assemblies are a more suitable choice. Once you decide to use, at least some, private assemblies for multiple applications - you should consider using private assembly library.
From now on, when you choose Manifest / Private Assemblies menu option in Manifest Maker, all assemblies from the library will be listed in the dialog. When you select any of them, they will be listed in the project item list as private assemblies with a note Library.
When building application manifests (either Automatic or Assembly Manifest project type), Manifest Maker will add this assembly reference to the application manifest and test the manifest with the private assembly reference.
A common way of installing private assemblies is through the use of Microsoft Installer's Merge Modules. See MSDN Library for details.