Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Alternative to Merge Modules

Created: 29 Jan 2007 • Updated: 14 Mar 2007 • 9 comments
Screenbert's picture
0 0 Votes
Login to vote

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.

Comments 9 CommentsJump to latest comment

FrankB's picture

Wouldn't that create a clutter on installation packages all together? With a lot of MSIs one might lose overview.

Starf0x

______________________________________________
Frank Bastiaens
Senior Technical Consultant
Vanderlet B.V.

0
Login to vote
Screenbert's picture

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

Screenbert

+2
Login to vote
erikw's picture

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

Regards Erik www.DinamiQs.com Dinamiqs is the home of VirtualStorm (www.virtualstorm.org)

*************************************************************
If your issue has been solved, Please mark it as solved
***********

0
Login to vote
rpfenninger's picture

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?

+2
Login to vote
Screenbert's picture

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

Screenbert

-2
Login to vote
Screenbert's picture

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

Screenbert

+4
Login to vote
piyushnasa's picture

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.

Piyush Nasa Altiris Certified Professional (ACP)

http://msiworld.blogspot.com/

-2
Login to vote
R-Vijay's picture

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.

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

-6
Login to vote
piyushnasa's picture

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.

Piyush Nasa Altiris Certified Professional (ACP)

http://msiworld.blogspot.com/

-2
Login to vote