When do you prefer Shared DLLs over Merge Modules?

Merge modules are similar in structure to a simplified Windows Installer, which helps to integrate shared code, files (DLLs / OCXs), resources, registry entries, and setup logic to applications as a single compound file.

Drawback of using downloadable Merge Modules while re-packaging: Most of the merge modules are present in their respective shared location, if not; it’s downloaded from the web. As the files integrated with the installer is from merge modules, it does not require isolation.
When you don’t find the proper network for the Share location on web during installation, then the application / installation fails to function. This is the main drawback of the Merge Modules. Shared DLL concept can be used to overcome this issue.
During the re-packaging process usually we don’t include the merge modules, that has to be downloaded during installation, in the WSI/MSI; this is to avoid the above mentioned network issues. The following screen shot shows how the merge modules will be excluded in the package:

In this case the DLL/ OCX files will be included directly within the WSI/ MSI.

Shared DLLs:
All the DLLs captured in the WSI/ MSI will be a shared DLL. When a DLL is already present in the machine and if we install the application, the DLL of the same version increments its DLL counter. Since the DLLs from the MSI are shared DLLs, any new application that would be installed on the same machine in future will increment the corresponding DLL count. All the Shared DLL counts can be viewed from the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls When there is a DLL conflict found using Wise Conflict Manager, we go for Isolation. This is named as DLL Redirection.

What is DLL Redirection?
Since an executable imports API functions from DLL files, DLL redirection allows us to tell a program that the DLLs it needs are located in a different directory than the originals; in this way we can create a DLL with the same name as the original, which exports the same function names as the original, but each function can contain the code of developer’s choice.

There are two ways to achieve DLL redirection;

1. “dot local” redirection:
   “Applications can depend on a specific version of a shared DLL and start to fail if another application is installed with a newer or older version of the same DLL. There are two ways to ensure that your application uses the correct DLL: DLL redirection and side-by-side components. Developers and administrators should use DLL redirection for existing applications, because it does not require any changes to the application. “
   In other words, dot local DLL redirection affords developers the ability to force an application to use a different version of a particular DLL file than that used by the rest of the system. For example, if an application called oldapp.exe only worked with an outdated version of user32.dll, then instead of replacing the user32.dll file in the system32 directory (potentially causing many other applications to break), you could tell it to load the older version of user32.dll from the program's current directory by creating an appropriate dot local file. All other applications will still load the newer DLL from system32 and remain unaffected. All that is needed is to create a dot local file (which is simply an empty file whose name contains the name of the target application followed by a .local extension; in this case it would be oldapp.exe.local), and place it and the older version of user32.dll in the same directory as oldapp.exe.
   Limitations with “dot local” redirection:
   Most notably, according to MSDN, certain DLL files (called 'Known DLLs') cannot be redirected in Windows XP (this restriction does not apply to Windows 2000). A list of all Known DLLs can be found in the
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs key; included in the list of known DLLs are kernel32.dll, user32.dll and gdi32.dll. However, this is not true - it seems that under Windows XP, an application will either allow you to redirect any DLL, or none at all. As such, if targeting a program running on the Windows XP platform, dot local redirection is an unreliable method, and should be used only on Windows 2000 machines.
2. Using Manifest Files:
   Manifest files use the same naming convention as dot local files (i.e., oldapp.exe.manifest), but are not empty files. They must contain certain XML-formatted information in order to function properly, or else the target application will fail to load. In addition, manifest files are only supported on Windows XP and Vista; however, they are far more reliable than using dot local redirection, and allow us to redirect any DLL file. (NOTE: The testing was done under Windows XP only; it is possible that some restrictions/changes may be applied to Windows Vista).