You're basically asking if the Component Rules exist & if so how do they work. See http://msdn.microsoft.com/en-us/library/aa370561.aspx & the pages its last paragraph links to.
Rob M wrote some very good blogs regarding the above which I'd recommend as "further reading" http://robmensching.com/blog/posts/2003/10/4/Windows-Installer-Component s-Introduction & http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 Palbinder Sandher Software Deployment & IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the <Virtual Environment>** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -----Original Message----- From: admiristra...@cox.net [mailto:admiristra...@cox.net] Sent: 04 March 2010 16:02 To: General discussion for Windows Installer XML toolset.; b...@joyofsetup.com Subject: Re: [WiX-users] Merge Module versioning, or equivalent Hi Bob, I guess I'm completely missing how to version files then. I don't find any attributes or child elements of component or file that seem related. I'm not aware of any consistent file-versioning aspect of the windows file systems. Also, I expect a need to version non-files, such as registry entries. In my current WiX project, shared items are overwritten with older versions and removed without respect for shared dependencies. I'm trying to correct that. I can't find an example of how versioning and sharing files & registry settings is supposed to work. Let's say I have two components: a "Shared File.txt" file and a "Shared Stuff Version Number" registry entry, installed by potentially one, two, or three otherwise independent MSIs. How can I specify that these components are shared and that reference counts(?) ought to be maintained so that installing any one MSI has everything it needs to operate, that a second MSI with an older version of the shared component does not overwrite the existing shared items but does officially depend on the shared components, and that a third MSI with a newer version of the shared items overwrites, maintaining MSI 1 & MSI 2's official dependency on them, AND that the MSIs may be uninstalled in any order, leaving the newest version of the shared items in place until all three MSIs have been uninstalled at which point no items remain. It would be acceptable if shared items had to be rolled back to the next-most recent version upon un-installation of the most-recent version - if that's just how it works. Am I off my rocker? It seems like complicated functionality, but it also seems that this would be a capability of the Windows Installer. Otherwise, what is this file-versioning for and what are reference-counts for? Thanks! On Wed, Mar 3, 2010 at 6:38 PM, Bob Arnson <b...@joyofsetup.com> wrote: > On 3/3/2010 4:14 PM, admiristra...@cox.net wrote: > > Can someone please detail how Merge Module versioning is supposed to > work? > > > > There's no such thing. Merge modules are a collection of tables and > rows that are merged into your .msi package, losing their identities > in the process. All versioning is based on component state, which is > based in part on the file versioning rules documented in the SDK. > > What problem are you having? > > -- > sig://boB > http://joyofsetup.com/ > > > > ---------------------------------------------------------------------- > -------- Download Intel® Parallel Studio Eval Try the new > software tools for yourself. Speed compiling, find bugs proactively, > and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------ ------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
