The IDs of components have a scope of the containing package. The Guids of components have a system-wide scope. As a result, you do need to fix this as soon as you safely can.
The following is from what I remember having run into this issue before. If one of the other gurus here knows differently, please chime in and correct me. I am also leading with what I believe to be the original reason for the following behavior, but I wasn't there when it was created. There are merge modules that install files into their indicated INSTALLDIR folders (or some subfolder of that folder) wherein when the merge module is used in several different and otherwise not related products several instances of that component will simultaneously exist with the keypath-file involved living in several places, so there has to be some level of support for this. One example is a merge module with a dll that has to be loaded from an application's current directory. Windows Installer deals with the scenario in a generic way, not directly related to the use in merge modules, as follows: If two products have a component with the same GUID but different keypaths (usually the same file in different directories) each keypath is recorded separately and related to the associated ProductCode. The keypath for each is treated as if it were the only keypath for that component, except that if the component is removed the keypath will be removed even if there are other products that also use that same component. The rest of the resources in that component (I hope there are not any) will be treated the same as with any other shared component, except that only the current product's related keypath is checked for versioning information (all other components seem to be treated as if they were "less-than" the current one). This causes installations and repairs to "overwrite" the component with the current package's resources. However, upon removal, if there are other instances of the component, the non-keypath resources will be left behind (possibly orphaning them) under the assumption that they are still being used by the other program's copy. The last package to remove the component removes its definition of the component in the standard non-shared way (since at that time the component is no longer shared). You can see components in this state where just the file-type-keypath is removed and all other component resources are untouched when the action state of the component shows in the log as "FileAbsent". This isn't the best state to be in, because it means that two programs sharing the same GUID that don't have matching versions may have registration data that is out-of-sync and a repair of the remaining product will be required to bring them into sync after the other product is removed. It also means that installing the second program with an older version will "downgrade" the component wrt the registration data, causing the earlier installed program to live with the older registration data (possibly pointing to the older more recently installed instance). It also means that registration data pointing to an instance just removed will remain when the remaining program is run. This scenario does, thus, produce one of the variants of DLL-hell, unless you are lucky enough that the only resource in your cut-and-paste component happens to be just a single file. -----Original Message----- From: Younie, Bradford [mailto:[email protected]] Sent: Tuesday, October 27, 2009 6:10 AM To: [email protected] Subject: [WiX-users] A question about components and their guids This is kind of a high-level question about components that I need to understand: What would happen in this scenario: I have two installers that install the same file to their own directory tree. When I defined each installer source, I did a copy/paste of the component for that file from one source to the other and neglected to change the component's guid on the second installer. Then I build each installer kit and run them both, one at a time, on my system. Would the files be installed in their proper places for each installer, or would MSI get confused because they have the same ID and guid? I guess the direct way to word the question is: does a component's guid only need to be unique within the product or module it's defined in, or must it be unique from all components installed on the target computer? I know it would be best to give them different guids, but I really need to understand how this works. Best regards, --- Bradford Younie ---------- Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
