Hi, Continuing the discussion after the three years.
To refresh the problem: We have several products that share component GUIDs between them. These products are in fact different configurations of the same project (Pro, Demo еtc.) with the similar file list. The products are installed side by side into different directories. Everything seemed to work fine not counting the rare reports from our customers that minor update failed to update some files on Vista and 7. We have no such reports for XP. Some days ago we built the shared component list with msiinv.exe -m and found that our components with shared GUIDs are listed as shared (!) on Vista and 7 (on XP with MSI 3.1 or 4.5 the same components are not listed as shared). As a consequence, these components are not completely independent of each other and there is a configuration where minor upgrade always fails. Steps to reproduce: Install product 1 Component A ver 1.0 goes to Program Files\Product 1\A.dll Install product 2 Component A ver 1.0 goes to Program Files\Product 2\A.dll Update product 2 Component A ver 1.1 updates Program Files\Product 2\A.dll Update product 1 Component A ver 1.1 DOES NOT update Program Files\Product 1\A.dll because it is considered to have the same version. Is there a way to solve this problem on Vista and 7 other than making .wxi files with different GUIDs for each configuration. Best regards, Ilya Slobodin -------- Original Message -------- Subject: Re: [WiX-users] How to keep guids in similar setups From: Mike Dimmick <m...@dimmick.demon.co.uk> To: 'John Vottero' <jvott...@mvpsi.com>, 'Ilya Slobodin' <islobo...@yandex.ru>, wix-users@lists.sourceforge.net Date: 16.10.2007 2:07 > Not necessarily true. It is OK to install the same component to different > paths; it is definitely wrong to install two different components to the > same path as then the references get cross-linked. > > Windows Installer tracks where every installed product installed every > component that it installed. When removing a component, it checks to see > whether any other product is still referencing that component at the same > install path - if not, it removes it. If there is another component not > installed by that product which installed the same file, the other product > will then be broken. > > When installing and removing components, the definition from the package you > are installing or maintaining is used. That's why you have to be very > careful with adding and removing files in components. If you produce a > (shared) component with files A, B, C and D and ship product P1, then add a > new file E and ship product P2, if the user installs P1 then P2 and removes > P2 then P1, file E will be left behind because it wasn't in P1's definition > of the component. > > If you change the component GUID you _must_ move the resources. This no > doubt includes ensuring that a user doesn't install a later version to the > same folder as an old one. > > Astute readers will realise that if you're performing only major upgrades > and you remove the old product before installing the new (i.e. schedule > RemoveExistingProducts between InstallValidate and InstallInitialize), you > can break a lot of component rules for private components that aren't shared > with any other products, because the old components are wiped out before the > new ones are installed. I'm not saying you should, I'm saying you're > unlikely to suffer the consequences. Do anything more complicated, with > shared components, minor upgrades, patches, or scheduling > RemoveExistingProducts anywhere else, and you quickly run into difficulty. > It's best to do it right to begin with so it doesn't affect > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
