Back to the original topic of merge modules: Merge modules simply provide components to a larger install. There is no concept of 'not installing if already installed' - the file versioning mechanism covers this. The components are reference-counted so that the component is maintained on the system until all products using the component are removed. Installation packages should, as far as possible, be self-contained.
If your component is completely compatible with the older version and directly replaces it, you should keep the same file name and install location (potentially retargetable) and keep the same component GUID, and increment the file version number. If not completely compatible, you should change the file name and/or install location and generate a new component GUID. These rules are general for all Windows Installer packages but are particularly important for components that will be shared among multiple packages. You probably do want to make your module retargetable - i.e. make the install directory configurable - so that your clients can keep their own private copies of the files, rather than installing to a shared folder. Only install to a shared folder if the component can only tolerate one version running on the system at a time, which is a very rare requirement - perhaps they use a specific format of shared memory section or shared data file format which cannot be made forwards- and backwards-compatible. Once merged, the module's identity is lost. There is no sign, from a Windows Installer level, that the module ever existed (there's a few traces in the component/file/etc names, that there's a GUID attached to each original name to ensure there aren't conflicts, but otherwise no sign, and nothing that can be queried). This means that you cannot, as the merge module developer, detect and patch files because you don't have the product GUID which is what Windows Installer uses to track that information. To service the contents of the module, you have to distribute the updated merge module to all the users of that merge module, and they have to update their packages and distribute them. This is one major reason why Microsoft are moving away from merge modules. The VS merge modules are OK to use because they rely on Windows' side-by-side assemblies feature, where a publisher policy configuration file can override the version specified in the application's manifest - the publisher of the component can override which version of the library will be used (although the application can then force the older version again through its own configuration file!) Windows Installer used to support nested MSIs but there's some reason that feature was deprecated (the engine still supports it for legacy products but the documentation now simply says 'don't'). Phil Wilson says in "The Definitive Guide to Windows Installer" that minor upgrades and patches aren't possible with nested installs - again the servicing problem raises its ugly head. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerome Haltom Sent: 30 May 2007 03:13 To: Bob Arnson; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] upgradable merge modules > That level of control isn't possible in a merge module. Provide an .msi > package instead. So, what's the point of merge modules then? If I can't distribute a third party library that other people can use as a dependency, what good are they for? And I don't think one can reasonable say it can be used as a dependency if two consumers installs will conflict. If I provide a .msi file, how will their .msi file include it? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
