Alternative to Merge Modules
Filed under:
Wise Package Studio
Application Compatibility
Submitted by Screenbert on 29 January, 2007 - 13:39.
Many times packagers use merge modules for applications to prevent conflicts when uninstalling that application later on. Here's a "best practice" to keep in mind when using merge modules.
There are drawbacks to merge modules, such as if a patch comes out for something in that module. You would then have to create a patch for each application you have.
You may find that it is better to ban merge modules altogether. Instead create a MSI for each of your merge modules and then make them a pre-requisite for the application that requires it.
The benefit of this is that when a patch comes out for whatever is in the merge module you only have to deploy one patch instead of a patch for each module.
(13 votes)
- Login or register to post comments
- 2997 reads
- Printer-friendly version
Hmmm
Wouldn't that create a clutter on installation packages all together? With a lot of MSIs one might lose overview.
Starf0x
Grouping
Simply keep all of your repackaged merge modules together. It would still be easier than patching each app if you have a large number of apps.
Screenbert
MSI packages
When you are afraid of losing overview, a program like virtual source safe is very fine.
You can always find the latest version, and in the virtual source safe the patches are completely listed.
Erik
Windows Protected Files
We don't patch our existing packages at all. As soon as an 'obsolete' package gets installed on a client, it gets patched through WSUS or other updating mechanism.
Aren't any of those file usually included in Merge Modules protected through the Windows Protected Files and not repackageable anyway?
Patches - WPF
That's a good point. Microsoft should patch most pieces in merge modules. But not every merge module relies on a patch from Microsoft. So this would mainly be used for non-Microsoft patches.
Screenbert
MS patches
Also a repair on your msi that included files that were patched would overwrite your patched files. Since WFP would protect most patched files, this would apply more to older systems or non-protected Microsoft files.
Screenbert
Merge Module is nothing
Merge Module is nothing more than a component, So instead of creating a separate MSI for it as you suggested will really not make a difference. When you add Merge Module to your WSI, after compilation it just becomes a normal component. To avoid conflicts you need to keep the attribute of the component to 8, which will make it a shared component to avoid conflicts. There is no need of creating Merge Modules or MSI for it.
My take on Merge Modules
Well, Mergemodule has always been into discussion everywhere.
We can very easily convert a MSM to a msi by using few isntaller tools. But whats the need of this???
AFAIK, These are the Pros/Cons of using Merge Modules:
1. Several WinSxS assemblies can be easily included in the package by adding the respective merge modules. (Atl80, Mfc etc.. which creates manifests and assemblies in WinSxS folder). Its really very tough to create a MSI which handles winsxs assemblies atleast on Vista.
2. Sometimes, few system files gets replaced by Merge modules without notice (but not WRP entries though). This may lead to a problem that, the other pre-existant application goes for a toss.
3. Merge modules can't be un-installed. (its the same as in System updates/hotfixes).
4. Merge modules gets installed with highest available privilages. This may replace files which are currently being held by few user applz.
I would advice using Mergemodules when I look at the first benefit.
My view
I totally agree with you Vijay for the first point, but my point here was to create a Merge Module from the captured package, which would be of no use. It is always encouraged to use the existing Merge Modules. My point was that if we have already captured the registries and files properly then what is the use of creating Merge Module, you can directly include that in the package.
Well regarding your other points, as per my knowledge I will say that Merge modules after compilation are nothing but the normal components of the MSI. The cannot be uninstalled because maybe in the Merge Module the component attribute is set to 24, which makes it a permanent component.
Merge Modules are pre compiled libraries of components and they do not have any special privileges to install. If you have other take on it, please let me know the article or an example, which can help all to understand it better.