3 replies to this topic

[Optic]

Hi All,

I would just like to get some general opinions on how most of you handle DLL issues with large corporate deployments using MSIs. I have been unable to find out much information about this and I'd like to encourage some discussion about it. If there are already topics that cover this then please feel free to point me in the right direction and I will read them.

Let's say that you have found yourself in a position where you are organising a massive corporate conversation to Windows Installer technology (lets say 500-1000 applications) where most of the applications need repackaging as they do not come as MSIs. How would you handle files (DLLs mostly) that applications install in locations other than their install directory (common files, system32 etc)?

Is there an accepted "best practice" for how it should be done? The Windows Installer SDK really does not tackle this kind of situation. It looks at MSI creation from the angle that you are the application author and you want to create an MSI for the world to use to install your application. Merge modules are also explained in the SDK, but again it is assumed that you "own" the DLL that you are creating the merge module for - ie you are creating a vendor merge module for your own DLL and you will distribute this merge module to people who may want to use it in their own package.

Obviously in a corporate rollout many of these assumptions are not valid. You may only be creating packages for a single standard SOE (rather than the "whole world"). You are repackaging someone elses application rather than creating an MSI for your own (a situation not covered in the SDK).

Is it considered best to create a homemade merge module for every DLL file that installs outside of the application directory (where no vendor merge module exists) and use this in every package that requires that DLL for the enterprise rollout? Is this a correct, valid and encouraged use of merge modules? Do enterprise rollouts build up their own libraries of homemade merge modules using this process?

Perhaps it is better to leave all files exactly where they are (if there is no vendor merge module) and use a conflict management tool instead. I am assuming that the conflict management tool would align component codes so that the counts for the various DLLs are correct and therefore uninstallation of one MSI should not break another (I'm not experienced with the use of conflict management tools and I am only guessing as to what they do).

Are there other ways to tackle the problem that I have not thought about? Is there an encouraged "best way"? What do people with experience recommend?

Cheers,

Optic

[Stefan Krueger]

As you already pointed out: if there is a vendor created merge module then you should use it.

Otherwise all you need to make sure is that same components use the same GUID in all of your packages. You can do this by creating your own merge modules, or using some tool, or even manually

Merge Modules have some advantages:

• They are re-usable. So you don't have to repeat all steps (catching COM registrytion information, manually tweaking, etc.) for each project.
  
• Besides files, registry entries and the like they can also include custom actions.
  
• You'd be able to share them with other departments or teams in your company, or even with peers in other companies. I.e. you could post them (e.g. here on InstallSite) so others can benefit from your work.
  

[hambone]

i would suggest the use of a merge module library combined with a conflict checker. unfortunately there are no commercially available conflict tools, that i am aware of, that provide a 'proper' conflict check. the use of a message digest summary such as SHA or SHA-1 is sorely needed in the commercial products..

if you find yourself re-packaging software and are using one of the standard studios, it will automatically scan your new msi for components that can be replaced with msms from your corporate library.

[Optic]

Hi Guys,

Thanks for your replies.

What sorts of rules would you recommend for deciding whether to create a merge module or not? Would you have a blanket rule along the lines of "all files outside the application directory must exist in a merge module"?

Perhaps you would leave files where they want to go, and only come back to applications if/when a conflict management checker told you that two apps installed the same DLL/file? Then of course you'd make a merge module for that DLL and include it in both of the apps.

Doing it this way leads to some timing issues where applications may have already been pushed to clients when a new application being packaged is found to conflict with the already pushed application. How would you handle this situation? I'm assuming you'd fix both applications and re-push the first one as an upgrade (or something along these lines). It starts to get pretty complicated.

If you ALWAYS create a merge module for every file outside of the application directory this saves the situation above from happening, but can add a lot of time to the packaging process. You can come across many applications that install 30 DLLs outside of their application directory and creating a merge module for each of these can be tedious, especially when it may well be that none of your other applications will ever use those files.

I'm interested in specific methodologies that are known to work well in large corporate rollouts.

Thanks for your input so far.

Cheers,

Optic