views:

509

answers:

2

I can find plenty of info on how msi upgrades. E.g. info about minor upgrade, small upgrade, major upgade, and their use case and limitations. However, I cannot find info on the upgrade behavior of merge module, such as:

  1. It seems like msm does not have any way to specify minor, small, or major upgrade. So which way it behaves in? Does it uninstall old version first or only update changed files?
  2. Is there any way to specify from which version it can be upgraded like msi?
  3. Can I add/remove/rename components for new version?
  4. If a newer version of this msm is already installed and the container msi decides to install, will it overwrite with this older version of msm?
+2  A: 

There are two upgrade scenarios that a merge module can take part in. The first is when the installer is upgrading, and it upgrades a .msm file. This happens in cases like the Visual Studio service pack where they provide updated merge modules for you to use. This can be problematic as .msm files do not have a file version (even though they have a merge module version), so file versioning rules do not apply kindly. You're probably not asking about this case.

The other scenario is when the merge module has been merged into an installer that will upgrade. It is no longer a merge module, but instead its files and other records are part of the consuming installer. In this case, the .msi into which it has been merged controls the upgrade steps. The two interact, informing your answers to your first three questions. If the merge module has changes that do not follow minor upgrade rules, then the consuming installer will be unable to use a minor upgrade, and must resort to major upgrades. Correspondingly if you want to use (or allow) minor upgrades in the consuming installer, you must be careful about your components. This can be harder than in an .msi since you cannot add new features inside a merge module. File versioning rules will apply just like they do in all Windows Installer installations; thus the answer to your fourth question is determined on a file-by-file, component-by-component basis instead of a group answer for the entire contents of the module.

Michael Urman
Great answer. It does be the second scenario. The windows installer picture is getting clearer to me...
Dudu
A: 

Question: I believe I need to know how to version the merge module as described in the second scenario in the answer.

Situation:

I have numerous products that all install the same merge module.

If one product installs a newer version of the merge module I do not want an old version of a different product to overwrite the newest merge module.

Can someone describe if this is possible and if so how?

gollumullog
This really should be its own standalone question (refer to this one as necessary). If the merge module and its newer version are authored well, this should just work. The newer file versions will overwrite the older ones but not vice-versa. The shared component codes will reference count correctly so uninstalling even the single user of the newest files will not remove the shared files. In a nutshell: make sure to follow component and file versioning rules, and ideally just update existing files, when upgrading this merge module's design. Then all should work fine.
Michael Urman

related questions