Well that is all very unfortunate. Is there a way to have a component encompass changing files? For instance, from one compatible version to another, files may in fact be removed and changed: those files were used internally. My main problem seems to be that components cannot contain directories. If this was possible, I would simply put the entire installer into a single component, and only change component IDs when there was no compatibility between versions.
What a bother. I do not want to allow software to use a private copy of this library. I don't really have much reason for that other than I don't want two copies loaded at the same time, as there is a large memory issue. On Thu, 2007-05-31 at 20:39 +0100, Mike Dimmick wrote: > 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
