4 replies to this topic

[spdygnlz]

Does anybody know of any strategies of creating merge modules and deciding what goes in them?

My current issue is that we have a software product that includes thousands of files, most of which have dependencies on other files within the project. We have another product that integrates with the first one and uses most of the same dlls. I've taken a sample of the files and mapped out all of the interdependencies. In this group of about 30 files, I've identified about 8 files that don't have dependencies on them. At first I figured that these would make good candidates for merge modules (1 file and it's dependencies per merge module). I kept the component codes the same for all of the shared components because I want the Windows Installer engine to correctly handle them in terms of uninstalls, repairs, already installed files, etc. The problem that I ran into, of course, is that when I merge them into a project, there's duplicate components in all of the merge modules.

In other words, say I have 4 files A, B, C, and D. Say C depends on D, A depends on C, and B depends on D. using my method above, I'd make 2 merge modules: One that includes A, C, and D, and another that includes B and D. Obviously D is common between the two.

[spdygnlz]

Oh, and sorry about the poor diagram. I'm not an artist - ASCII or otherwise. I hoped it would help people visualize the situation.

[KathyMorey]

The idea behind merge modules is to encapsulate files that are needed by more than one product, so that they can be shared.

So, in your scenario, D belongs in a merge module by itself. If A and C are always installed together, you could put them in one merge module, and that merge module could be set to have a dependency on D's merge module.

B could be in a merge module by itself, with a dependency on D's merge module.

However, any files that are used in only one product don't need to be put into a merge module; they can go in the project for the product directly.

Hope this helps!

Kathy

[spdygnlz]

That sounds reasonable, but why would I make a merge module with only 1 file in it? It kinda seems like it defeats the purpose.

[KathyMorey]

That depends on where that file is consumed. For example, we have a suite of products, and the majority of them use a .dll that handles logging of internal status messages. So I put that one .dll in a merge module which is then consumed by every project that needs it.

Customers can purchase and install various combinations of products, and that .dll will be managed by Windows Installer so that it won't be uninstalled until the last product that uses it is uninstalled.