Innovative Application Packaging Cloud

Innovative Application Packaging Cloud
Automated Packaging Self-Service (APS) is an innovative cloud solution that provides smart application packaging, testing and documentation.

Wednesday, October 05, 2011

Merge Modules


  1. Merge modules are a mechanism in Windows Installer that allows software companies to repackage and share standard component definitions.It enables the encapsulation of a component or set of related components and their resources, and the subsequent merging of this module with install packages which require the component or component-set.
  2. Merge modules cannot be run separately and are used to add information to an installation package at compile time. After the merge is complete all the information in the merge module is incorporated into the MSI.
  3. Merge modules contain tables not found in an MSI and a couple of these tables such as ModuleSignature and ModuleComponents are Required. These tables list the information identifying the merge module and the components included in the merge module respectively.For a full list of the tables unique to merge modules refer to the Windows Installer SDK under the topic Merge Module Database Tables.
When to make merge modules:

 
It is then necessary to separate files:
o Used only by the application
o Those that are Shared Components.
• Shared Components are files which are used by other applications. Such files are: .DLL, .OCX, .TLB, .OLB, .EXE and other support files as required (e.g.HLP).

These files are usually files that install to:
1. WINDOWS\System32
2. WINDOWS\System
3. Program Files\Common Files\
or Program Files\Common Files\System\
or Program Files\Common Files\Shared\
or Program Files\Application Folder\Shared\

• Both 16-bit and 32-bit components installed in a shared directory should normally be considered shared.
• Both registered and unregistered components installed in a shared directory should normally be considered shared:
o Normally any component that an application setup installs to a shared directory is a shared component. Even if unregistered.
o An unregistered shared component can be moved to the application directory. It then must be checked if the application works with it or not.

Sometimes it is possible that a setup may install a component to a shared directory, but it is really not shared. The first thing to do is to check the vendor name of the DLL/OCX in the shared directory if unsure.
• If the vendor name is different from the other vendor names of the files in the shared directory then try to put it in the application directory. This should only be done if the packager is sure that the application function will not be jeopardized by this change.
• Different applications provided by the same vendor may use some shared components the application vendor created. In this case such components should be considered as being shared, since they are shared between applications provided by the same application vendor

Encapsulate files as much as possible.

If a set of files go together, they should be created as a Merge Module. Merge Modules can contain other Merge Modules in a hierarchical way, so this technique can be used where Merge Modules are dependent on other Merge Modules.

The following cases indicate where this should be done:
OCX + dependent files (DLL’s, TLB’s, HLP’s etc)
DLL + dependent DLL’s

File suites where it is not clear exactly which files are used. In this case the safest thing to do is to include all For simplicity. Although it is always possible to create a Merge Module for each file, it is not necessary, since this would include adding a lot of Merge Modules to a package rather than one.


Where are they used and what are the Advantages:
  • The primary reason for using merge modules is to put together a package that other groups can use in their installations.
  • If a piece of functionality is likely to be reused within multiple products it should be set up in it’s own merge module.
  •  Merge modules contain all the information required in a single file.
  • They can save the user from having to individually install the same files, registry entries and other components to several installations.
  • This helps prevent potential problems, which could be encountered when manually installing files, registry entries, etc. In doing so merge modules provide re-usable code thus reducing TCO (total cost of ownership).
  • For example, suppose you have many applications that require the same version of Visual Basic runtime. Well, instead of individually adding the files, registry entries, etc., to each of your installations, you can create a merge module that installs and configures the Visual Basic runtime, and then you simply add this merge module to each application package.
  •  When we need to update the configuration of the Visual Basic runtime, instead of updating all the installation packages, we simply update the merge module and then recompile the packages containing that module


    • When not to make Merge Modules:
      A component should not be made into a merge module if:
       The application installs the file into it’s own directory.
      • Files found in WINDOWS\System32\Dllcache are used for Windows File Protection.Also files found in this location should not be in any package.
        

      No comments: