Actually, you can have two components sharing the same GUID installed into different keypaths by two different products (or any other number besides two) as long as certain very strict "rules" are followed:
Any/all non-file resources in the component may not be removed until the last of the components are removed. If any of the resources point to the installation location of the component's keypath, then that registration can be broken if the last product to be installed is removed before some other product is. Thus, all except the files in the component should always be identical in all products AND not refer to the installation location of the component's files. To understand what I am describing, here is a table that describes the way that the product registration of components is achieved: For any arbitrary component XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX: ProductCode KeyPath AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA C:\Abc\Def\Ghi.txt BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB D:\Nopqrs\Ghi.txt etc. Here is what happens in that instance: The first product is installed. All goes according to everyone's understanding, and the component is registered with its keypath to the product installing it. The second product is installed. The additional file(s) is written to the filesystem and the other resources are rewritten (I hope they were identical). The component (with the new keypath) is also registered to the new Then any of the two products is removed. In your verbose logs you would see that the final state of the component will be "FileAbsent". RemoveFiles will delete the files in that component but Registry entries will be left behind (since there are other clients of the component). Then the remaining product is removed. Since there are no other clients of the component, the component will be completely removed. If your component isn't "identical" (except for installation directory) between the two products, however, unexpected things will happen (orphaned/unserviceable resources, etc.). JKLists, as long as you don't change anything (except maybe the version/content of your file(s)) in your "sort-of-shared" components AND as long as all non-file resources in those components don't include/reference the installation directory, you should be fine. This isn't, however, a best general practice recommendation. I don't recall if this is documented or not (try searching on "FileAbsent" to see if anything shows up) but it is a weird-enough behavior that I wouldn't recommend it for except for the simplest of components, and even then I would recommend avoiding it. A better suggestion is to use Guid='*' in your shared components in your WIXLIB files you share across projects, with the possible exception of components that "force" themselves into specific directories, like the C++ runtimes Pally mentioned. -----Original Message----- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, November 23, 2009 4:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Shared assemblies Essentially "two installers listing the same component GUID in separate locations" is how things like the VC++ redistributable merge modules work. For example, your installer puts the VC++ 2008 redistributables onto a users machine. My installer then does the same. Both of our installers use the merge modules. The user then uninstalls your application but my application still works fine. Why? Because the Windows Installer tracks how many applications have installed the same components & will only remove components when there are no applications left installed which require them (annoyingly this is called "Shared DLL reference counting" when it actually refers to Components which can contain anything not just DLL's). This is explained in the Remarks section of the Component Table page on MSDN -> http://msdn.microsoft.com/en-us/library/aa368007.aspx Personally I have a number of fragments shared between 2 installers however in our situation you can have only one or the other installed & I use the major upgrade functionality to ensure a one way upgrade path from the smaller package to the larger one. I could create a wixlib (or merge module) containing the shared fragments & then consume it in both installers but as I have my project files in the same directory it works fine as is using Votive (and saves the extra build step of creating the wixlib/merge module). If your projects are in different directories however you will find Visual Studio will make a copy of the file into the second directory when you add it to your second project (hence why I have both project files in the same directory to avoid having to update 2 copies of the same code). Depending on how many people need to build your code on a regular basis you may find implementing the shared code in a wixlib (or merge module) a more robust solution. Good luck. 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: JKLists [mailto:jkli...@ifm-services.com] Sent: 20 November 2009 23:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Shared assemblies If I had two applications which shared some core assemblies, how would these handled between two installers? If I shared a WiX fragment source file between two WiX projects, the components would have the same GUIDs. Would that cause a problem or conflict? Could the two projects be installed, for example, on two separate drive letters? I'm not sure if MSI insists on having only one instance of a component with a particular GUID, or if it tolerates two installers listing the same component GUID in separate locations. Any recommendations on how this is supposed to be handled? Thanks! ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
