Software Deployment

One client site we did create merge modules for internal DLLs only. I have had issues with Crystal Reports, MSDE, and managing Visual Studio merge modules. I am curious to hear others opinions with real world merge module grief.

Conflict management is nice but very few sites I have seen will even use that feature. Most could care less about the proper deployment of MSIs because they have to meet production quotas usually set by some project manager that does not fully understand the technology. It also comes down to the fact that is there value in properly preparing each MSI so that it will not cause conflicts. So far I have yet to see a site perform a textbook MSI deployment. Usually the conflict management tool is only used after a conflict had been reported from the production environment.

A couple clients asked me for informal best practices with merge modules. All I could come up with is trial and error. This has always been a thorn in my backside as to how you manage a merge module repository. We all know there are bad merge modules and good ones. I guess this becomes a really complex subject because you almost have to evaluate the modules one by one to determine if they are suitable for implementation.

I think people here are forgetting that there are badly written merge modules out there as well as a lack of solid guidelines to ensure that your repository is providing maximum benefit. It gets even worse when you have vendor merge modules and then merge modules written by Wise for example. Which are more suitable for the repackager?

How about when your merge modules are not current with the latest binaries being released by the vendor? Are they still usefull or will they just cause issues down the road?

Are merge modules all that usefull if you are capturing COM registrations as straight registry data?

I think management of merge modules is often overlooked by many packagers and I am still looking for a solid set of practices to ensure my merge module repository does provide maximum benefit to the client. I know this is a sloppy post but hopefully it will stimulate a good arguement. [:D]

Wow, What was that? [8|]
Back on topic!

Download MSM-to-MSI Converter

You can download MSM-to-MSI Converter for free here:

http://www.ethalone.com/download/msm2msi.zip
SKJ Zero-G has another good web document explaining merge modules here.

Merge modules provide a standard method by which developers deliver shared Windows® Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, registry entries, and setup logic to applications as a single compound file.


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/merge_modules.asp

That doesn't necessarily mean that you have to use them. Many people who are knowledgeable about MSI choose not to for various reasons.

People who only create packages for their own environment(s) and who have a rigourous conflict management process may decide that they don't want the extra burden of merge modules.

well said

I've had multiple Microsoft reps advise against using merge modules. Their take on it was "Manage files, not merge modules". Just an FYI

Thanks for the "FYI" strakm - that definately is interesting!

However, I still think that it depends on your particular situation. While merge-modules might not be particularly useful in your environment, they might be of benefit to someone else.

I've had multiple Microsoft reps advise against using merge modules. Their take on it was "Manage files, not merge modules". Just an FYI
That is good advice if you are doing application isolation on ALL of your desktop applications.

But if you are mixing vendor supplied MSIs with your own home grown packages or repackages and are not isolating at least those packages that you build, you are headed for trouble if you are not using the most common sets of merge modules, (available here).

One of the most confounding issues of “dll hell” is when you push out an uninstall of an application and it removes a shared dll that several of your other applications are relying on. In which case you may receive helpdesk calls about multiple self-heals on multiple applications. If there happens to be an application that had a shared dll with an incorrect or missing keypath (from the vendor of course, WE would never make that kind of mistake! [;)]), you then have a broken app and have to do a manual repair or even a reinstall of the app or apps ... (ah a desktop visit or remote control session times a couple of thousand).

Been there done that. I use the merge modules.

Hi Bob.

Are you sure you meant to write "isolation"? I'm not sure that isolation (as in "Isolated Components") would help in the scenario you've described?

I'm assuming you meant to say "Conflict Management" or something along those lines? In which case, I completely agree.

ORIGINAL: WiseUser

Hi Bob.

Are you sure you meant to write "isolation"? I'm not sure that isolation (as in "Isolated Components") would help in the scenario you've described?

I'm assuming you meant to say "Conflict Management" or something along those lines? In which case, I completely agree.


Read this: Resolving Conflicts with Application Isolation. Both InstallShield and Wise products offer a wizard driven method to achieve Application level isolation.

Component level isolation is generally not a good idea. You should really aim for complete isolation at the application level, if you are going to do it at all. There are a number of large networks that will only deploy applications if they are entirely isolated.

Conflict management, the process of minimizing potential software packaging conflicts, would be a good general heading for this entire discussion. What I am presenting is but one of several alternatives for conflict resolution. Use of merge modules, isolation (component or application), package validation, etc are all methods with which we are trying to achieve the nirvana of conflict free desktops.

Just to clarify, there is an ongoing debate about weather or not to include Merge modules in isolated applications. I fall on the "Do not include modules if isolating" side of that discussion. But I may very well be wrong about that as there are plenty of Desktop Engineers who I respect that think that one should ALWAYS use merge modules for those common shared components no matter if isolating or not.

ORIGINAL: kkaminsk

I think people here are forgetting that there are badly written merge modules out there as well as a lack of solid guidelines to ensure that your repository is providing maximum benefit. It gets even worse when you have vendor merge modules and then merge modules written by Wise for example. Which are more suitable for the repackager?

How about when your merge modules are not current with the latest binaries being released by the vendor? Are they still usefull or will they just cause issues down the road?

Are merge modules all that usefull if you are capturing COM registrations as straight registry data?

I think management of merge modules is often overlooked by many packagers and I am still looking for a solid set of practices to ensure my merge module repository does provide maximum benefit to the client. I know this is a sloppy post but hopefully it will stimulate a good arguement. [:D]


Hi kkaminsk. I think you've made some interesting points!

A Wise employee once told me that they don't create the MMs that they distribute - they only distribute Vendor ones. But the only time I ever spent any time investigating that claim, I found mismatched component GUIDS between some MM components supplied by Wise and some supplied by Installshield - Crystal Reports onces to be precise. So somebody must be creating them!!

It is my experience that most people who use merge modules limit themselves to small number of (mostly) vendor supplied (usually MS) modules. It it unusual for people (at least in the repackaging world) to create and manage their own merge module repository. In this scenario, by keeping your modules up to date, you should also be insuring that you're distributing the most up to date resources.

I know that some companies have gone down the route of creating a new MM for every "shared" resource they ever install in their environment! I'd love to know whether they end up regretting this in the long run or not!? Anyone in Melbourne care to comment?

I get the feeling you create your own MMs too kkaminsk? If so, do you use a conflict management tool as well?

Regarding Isolation, Some tips and tricks can be found here As you can see you can completly isolate a file to the degree that it is never installed to the typical "Shared" location.

kkaminsk Regarding Bad Merge Modules, My favorite is the BDE merge module, which can't be extracted unless you have a copy of Delphi installed.

link to an article describing the downside of isolation

VikingLoki posted about Isolation and merge modules just the other day.

On another note: WiseUser you said "Although an "isolated" copy of the "isolated" file is made in the local application folder, the principal copy is still installed and registered in the shared location." Only if you chose that option, it is not a requirement. Please check the PM I sent you.

Hi kkaminsk (and everyone else in the thread)

Perhaps it might be the easiest to have a base set of merge modules you "trust" and have everything else captured as part of the package. My general method is to trust the base MM's that incorporate the Microsoft system stuff from either Installshield or Wise, mainly because I've never had any problems with them (when I say Microsoft System stuff, I'm referring to ADO, DAO, etc).

I've tried some vendor provided MM's and had problems, so I try to avoid them where possible, but its not a hard and fast rule. You are right, its a tricky situation, and some (MSIMaker being one) recommend forgetting about Merge Modules altogether and repackage everything in a totally isolated environment. I have to say, for all the clients I've had, none have gone for isolation and when I explain to them the benefits they look at me like I'm from another planet - this includes high availability sites where any downtime costs them tons of money. Perhaps this has more to do with the way I'm explaining it :)

Anyway, where I'm not concerned about isolation, I tend to use MM's for the Windows System stuff and worry about vendor specific bits myself. I use the MM's that come with the packaging tool I use for that client (which is usually either Wise or Installshield) and don't download any of the vendor/public created ones unless its an emergency.

Not the most coherent post I've ver made, I haven't had breakfast or coffee yet

Paul

ORIGINAL: BobTheBuilder

Regarding Isolation, Some tips and tricks can be found here As you can see you can completly isolate a file to the degree that it is never installed to the typical "Shared" location.

kkaminsk Regarding Bad Merge Modules, My favorite is the BDE merge module, which can't be extracted unless you have a copy of Delphi installed.

link to an article describing the downside of isolation

VikingLoki posted about Isolation and merge modules just the other day.

On another note: WiseUser you said "Although an "isolated" copy of the "isolated" file is made in the local application folder, the principal copy is still installed and registered in the shared location." Only if you chose that option, it is not a requirement. Please check the PM I sent you.



I have no reason to take this offline - I'm striving to keep this topic correct so that it may be of some benfit to those who read it later. So, what I have to say is best said here.[;)]

I'm sorry if you took offense at my post, but I try to keep the information wthin the threads that I post in relevant and correct (as much as possible). Whether it pleases you or not, "isolation" has nothing to do with this topic which is "Why Merge Modules?".

Although you've now edited your post to say something different (I still have copies of your original posts in my email account), this thread is still supposed to be about "Merge Modules" not "isolation".

I often contradict things which others have submitted if I believe that the material is incorrect (or irrelevant). Every single one of them has put their hands up and admitted when they've posted something "dubious" - and I respect those guys for doing so. If I post something wrong, and someone points it out to me I'll do exactly the same thing.

When you quote me in future, try not to misrepresent what I said... If you reread my post, you'll notice that I was talking about ".Local isolation" which is a type of isolation used in MSI (documented in the SDK) - there are no "options" to select, it just works the way it works. What I'm guessing you might be referring to is some "homemade" Wise solution?

I did not mean to upset you, especially as you awarded me a couple of points the other day (I hadn't forgotten that). If I was a little less than diplomatic (I guess that's maybe what "flaming" means?), then I apologise publicly for that.[:D] But I believe my posts were relevant and technically correct. If someone (you or another) posts something incorrect in future, I'll contradict them too. I'm not going to start sending people PMs to put them straight either - this is a forum.[;)]

Anyway, I hope we can forget this little difference of opinions and get along in future. I'm not to bothered about the two points if it makes you feel better! You gave me those anyway, so we're quits.[:D]

ORIGINAL: kkaminsk

Conflict management is nice but very few sites I have seen will even use that feature. Most could care less about the proper deployment of MSIs because they have to meet production quotas usually set by some project manager that does not fully understand the technology. It also comes down to the fact that is there value in properly preparing each MSI so that it will not cause conflicts. So far I have yet to see a site perform a textbook MSI deployment. Usually the conflict management tool is only used after a conflict had been reported from the production environment.



Excellent! I'm not the only one who has experienced this (constantly).

Not to mention the fact that an unfortunate proportion of "packagers" hired by companies to do their packaging wouldn't have the knowledge to use the tool correctly anyway!

I just want to join in and say that the company that I'm currently contracted on DOES USE the Wise Conflict Manager. What a god-send!!! [:)][:D][:)]

What Are Merge Modules?
Merge modules are a feature of Windows Installer that provide a standard method for delivering components, insuring that the correct version of a component is installed. A merge module contains a component, such as a .dll, along with any related files, resources, registry entries, and setup logic.

Merge modules are essentially simplified .msi files, which is the file name extension for a Windows Installer installation package. A standard merge module has an .msm file name extension.

A merge module cannot be installed alone because it lacks some vital database tables that are present in an installation database. Merge modules also contain additional tables that are unique to themselves. To install the information delivered by a merge module with an application, the module must first be merged into the application's .msi file.

A merge module consists of the following parts:

• A Merge Module Database containing the installation properties and setup logic being delivered by the merge module.
• A Merge Module Summary Information Stream Reference describing the module.
• A MergeModule.CABinet cabinet file stored as a stream inside the merge module. This cabinet contains all the files required by the components delivered by the merge module.
More information on this subject can be found here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vbconWhatYouNeedToKnowAboutMergeModules.asp

Read the above quote at the excellent SQL Junkies site
Merge Modules are also used by developers using MS Visual Studio and .NET Framework

And this:

Preventing File Overwrites with Application Isolation Wizard
The new Application Isolation Wizard tool, designed specifically for Windows Installer-based .MSI installations, gives you a convenient way to isolate applications and shared .DLL and .OCX support files. Isolating these files ensures that a deployed application always references and uses only the shared file version with which it was installed. This creates a smoother installation and prevents previous versions of shared support files from being overwritten.

When you use the Application Isolation Wizard, the .EXE files in your installation are isolated. Their dependent, shared .DLL and .OCX files are placed inside the application installation folder. For example, suppose your installation is named MyApplication.msi and the installation folder is C:\Program Files\My Company. When you use the Application Isolation Wizard, the shared .DLL and .OCX support files for the .MSI are placed in the C:\Program Files\My Company folder. On the Windows XP operating system, these files could optionally be placed in the WinSxS directory.

At Application Isolation Wizard runtime, you select either Windows XP manifests or the standard Windows Installer isolation component rules for the isolation process. In addition, you can select either to have the Wizard automatically isolate components or to manually choose the files and isolation methods.

Read it all at this Wise tips page

Nothing homegrown there...

Repair support for isolated files:

Install isolated files in the application directory only - Select this option to add self-repair functionality for the isolated .DLL by redirecting the installation of the .DLL from the shared location to the application directory. This prevents a copy of the .DLL from being installed to the shared location regardless of whether the .DLL is already in the shared location.

From Wise again, read it all here.
Merge modules provide a standard method by which developers deliver shared Windows Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, registry entries, and setup logic to applications as a single compound file.
When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file.
Because all the information needed to install the components is delivered as a single file, the use of merge modules can eliminate many instances of version conflicts, missing registry entries, and improperly installed files.

This is becoming very tiresome.[&o]

For the last time:

1) Isolaton cannot be used as a substitute for merge modules - they do entirely different things. Get over it.

2) You are mixing up Wise Package Studio features with MSI features. You obviously have no understanding whatsoever of what's happening in the background (from a purely MSI perspective).

3) I have no desire to discuss the pros and cons of isolation techniques with you - especially not in a thread called "Why Merge Modules".

I intend to ignore any further posts by you in this thread. You have turned this discussion from an interesting debate about the "usefulness" of merge modules into an incoherant rant about some dubious Wise Package Studio "isolation" functionality.

What was what?

Probably the sound of the Appdeploy cash register!!![:D]

_____________________________

Can't buy me love....

ORIGINAL: skj

Why Merge Module?


I bet you wish you'd never asked?

I certainly wish you hadn't![:D]

I don't know why you have it in for me WU. But since you already do ... I don't feel too bad having to irritate you again.

You said: "2) You are mixing up Wise Package Studio features with MSI features. You obviously have no understanding whatsoever of what's happening in the background (from a purely MSI perspective). "

This from the Windows Installer SDK

By using isolated components, authors of installation packages can specify that the installer copy the shared files of an application directly into the application's folder rather than to a shared location. This private set of files are then used exclusively by the application.

Installing a COM Component to a Private Location
To force a COM-client application to always use the same copy of a COM-server, author the application's installation package to specify an isolated components relationship between the COM server and client. This installs a private copy of the COM-server component to a location used exclusively by the client application. Do the following when authoring the package:

Put the COM server DLL and the .exe client in separate components.
Enter a record in the IsolatedComponent table with the COM-client component in the Component_Shared column and the client application in the Component_Application column. Include the IsolateComponents action in the sequence tables.
Set the msidbComponentAttributesSharedDllRefCount bit in the Component table record for Component_Shared. The installer requires this global refcount on the shared location to protect the shared files and registration in cases where there is sharing with other installation technologies.
Windows Installer version 1.1 or later is required.

There is more, but I think that if you are interested enough you will look it up yourself. That is hardly "mixing up Wise Package Studio features with MSI features".

As for becoming a paying member. Why don't you? You obviously enjoy yourself here and its worth the small amount of cash for all of the benefit we all receive here on a regular basis. Plus I can expense it, so my firm is picking up the tab. [;)]

ORIGINAL: strakm
I've had multiple Microsoft reps advise against using merge modules. Their take on it was "Manage files, not merge modules". Just an FYI
Sometimes that is easier said than done. One merge module that I have had a tremendous amount of good luck with is the Crystal 8.5 module. This thing has worked for several of our little data apps that were always a bit if a problem before. It was tough to manage the several flavors of Crystal out there as they were not always backward compatible.

Between some updates to those apps and better backward compatibility in Crystal 8.5, this MSM has really been an improvement.

There are merge modules for later versions of Crystal availlable here.

Hello again Bob.[&o] You're like a dog with a bone![:D]

I said I wouldn't answer you again within this thread, but I will for two reasons:

1) Some "unfortunate" wording in the SDK documentation "appears" (although it's only an illusion) that you may have a slight point regarding one of the two things I accused you of.

2) You've shown some commitment to this site - even if I don't trust your motives (you've got to admit that you're timing was perfect).[;)]

I don't "have it in for you" at all - I lost patience with you for the following reasons:

- you spat your dummy and took it upon yourself to deduct points from me because I disagreed with you. If everyone here did that, I'd have a negative score.
- you can't admit you're wrong on a single issue.
- you sent me an incomprehensible PM and then suggested online that this was supposed to have proved your point?
- you retrospectively edited some of your posts in an attempt to cover your tracks.
- you won't give up your futile cruisade to convince me and others that isolation can provide an alternative to merge modules?

Once we finally put this thread to bed, I'll respond to you in the same way I do any other Appdeploy member. I don't hold grudges.[;)]

Anyway, I believe there is some "dubious" wording in the SDK documentation regarding ".Local" isolation (as you pointed out): "Authors of installation packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into that application's folder rather than to a shared location". This sentence was taken from here:

http://msdn.microsoft.com/library/en-us/msi/setup/isolated_components.asp

I agree with the whole sentence except for the part that says "rather than to a shared location".

Here's how isolated components are installed:

http://msdn.microsoft.com/library/en-us/msi/setup/installation_of_isolated_components.asp

Notice that if "Component_Shared" isn't already installed, it will be installed by the "IsolateComponents" action.

The "IsolatedComponent" table only has two rows ("Component_Shared" and "Component_Application"):

http://msdn.microsoft.com/library/en-us/msi/setup/isolatedcomponent_table.asp

So there doesn't appear to be any room for "customising" the IsolatedComponents behaviour. If someone can PROVE to me that this behaviour can be modified, then I will be more than happy to learn something new.[;)]

I do think that the wording of the SDK could be better, and I can understand why you may have misunderstood the functionality.

Have I finally convinced you, or are you going to search the far-flung recesses the internet for another dubiously worded document to add further confusion to this never ending thread? Has it even occurred to you that I might be right?

Maybe another experienced member might care to contribute his opinion and put us all out of our misery!? I know Mr Hunter is lurking - enjoying the entertainment without committing himself![:D] Or one of the moderators might wish to share their wealth of expertise?

(6-10-05 Edited out off topic content.)

You are reading words into my posts that simply don't exist.

I did post some of the info that is available out there about Isolation, only because you made such an issue of it. I offer no advice anywhere in this entire thread other than to use the standard merge modules if faced with the choice.

If the single sentence that I posted at the top of this thread sounded to you like I was saying you can use Isolation in place of merge modules, then I apologize profusely for your misunderstanding.

Alllllllrighty then.... I've read the entire thread from start to finish a couple of times now, and can actually agree with you both. However, I do agree with WiseUser (RE: Why Merge Module? - 6/6/2005 9:54:06 PM) that Isolated Components is not a replacement for Merge Modules as even though the file is 'isolated' in the Application folder, the registry keys still exist.
Further more, "Application Isolation" (using .manifest files) can be the way forward if Merge Modules are not to be used within the environment. But of course, this has it's own set of issues (ie: No other program can talk directly to installed components as no Class, ProgID, TypeLib information is held in the registry etc.

Anyway, I think it all depends on the environment.
If working in a Software House packaging in-house developed applications, then 'application isolation' can be the way forward if the application is self-contained (ie: non-interaction with any other applications). Otherwise official Merge Modules (MS etc) could be used and in doing so will keep the component GUIDS matched up. Though I have also seen dodgy MM too.

Of course in a repackaging environment, the company can agree a policy on the version of shared DLL files on the standard desktop environment (SDE). In conjunction with a Conflict Management Tool, this can eleaveate the problems caused by "DLL Hell".

In conclusion, it all really depends on your environment and your experience with MSI's. In the past few companies that I've worked for, we have implemented Wise's Conflict Management tool and attempted to use "Application Isolation" where possible. We also have configured a MSI to deploy all the known common shared DLL files (Microsoft etc, VBRuntime, Crystal, Borland BDE etc). The only big issue in this example would be if we couldn't isolate an application but needed to upgrade one of the shared DLL files. Touch wood, this hasn't happened yet.

As you can see, it's a touchy subject. [;)] I'm out.

The only big issue in this example would be if we couldn't isolate an application but needed to upgrade one of the shared DLL files. Touch wood, this hasn't happened yet.
I can chime in here, as we have seen this, only backwards [:'(]. Disgustingly enough, the vendor mis-versioned a DLL, rolling it back from 7.x to 5.x! Conflict Solver came up with 10 apps that used the same DLL and eventually we decided to just take the 'new' DLL out of the package and give it a shot with the 7.x one. It worked, though the vendor pitched a fit at us for the change.

Maybe another experienced member might care to contribute his opinion and put us all out of our misery!?

No way! Sounds more like joining your misery to me! [;)]

Hey Bob! I'm sorry, but you seem a little bit confused.[;)]

The mechanism used to keep track (count) of resources installed by MSI relies on component rules:

http://msdn.microsoft.com/library/en-us/msi/setup/organizing_applications_into_components.asp

Merge modules help keep component GUIDs synchronised across MSI packages, as well as the design of the components themselves. This can be useful in the event that people don't have any other means of keeping GUIDS synchronised across packages - such as a conflict management tool.

Isolation makes a copy of a shared file in the local folder of an application in order to avoid a version conflict with the one in the shared location. It is a good tool for dealing with version incompatibilities, but it is rarely used as a matter of course for many reasons that I will not elaborate on right now. However, it DOES NOT synchronise component GUIDs.

With ".Local" isolation, all the resources which are related to the isolated file (advertising, registry, etc) are part of the component which is being isolated. Although an "isolated" copy of the "isolated" file is made in the local application folder, the principal copy is still installed and registered in the shared location. The shared copy of the file and all "related" resources would not be safe from removal in the event that another component with a different GUID were installed and then removed.

http://msdn.microsoft.com/library/en-us/msi/setup/removal_of_isolated_components.asp

Using "isolation" would not be a valid reason for stopping using merge modules.[:D]

It seems that our friend "the builder" has decided to do a little bit of demolition work tonight? As I've just lost two points![:D]

Unfortunately, it makes the whole points system a bit of a farce if this is what's going to happen.[:(]