Each of your files that stay in the same directories need to have components that keep the same guid values. If you don't drastically change your installation layouts from build-to-build (which is most of us) it is recommended that you write your installation once, and then update it on an as-needed basis (instead of autogenerating it each time).
The reason mismatching the component guids causes what you are seeing is as follows: NewProduct (over)writes the files in the installation based on what Windows Installer thinks are brand new components (the new guids). Then OldProduct erases the files (ignoring what versions or timestamps they may have) when removing the old components (since the components don't have any other products using them). The repair rewrites the files (since they are missing) and you are good to go (after the repair). Here is what happens when you push up the scheduling of RemoveExistingProducts: OldProduct removes its registration of all the components it contains, erasing all of the content for those components will no longer exist. Then NewProduct registers itself for each component it contains and writes their resources out to disk/registry, etc. Here is what you want to happen: NewProduct registers itself for each component it contains (making those components have two products) and overwrites the files that have newer version numbers (and possibly also overwriting those with the same version numbers depending on the value of REINSTALLMODE) as well as dealing with files that don't have FileVersion values as per the docs on MSDN. Then OldProduct removes its registration of all the components it contains, erasing the resources associated with any components that disappear as a result (along with any keypaths that don't share the same value with another product, including the one that just installed). The only way that happens is by making the component guids match. And the best way to do that is to not autogenerate them, or if you must autogenerate them, use "*" as the component guid values so that the binder will produce the component guid values in a stable way. -----Original Message----- From: Paul Brook [mailto:pbr...@vaytek.com] Sent: Saturday, November 07, 2009 3:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is this a GUID matching problem - how to resolve. I am building a WIX installer that will have to upgrade a Visual Studio deployment project .msi. When I run the major upgrade installer it replaces the entry in the Program and Features list OK but none of the files are left after the RemoveExistingProducts Before="InstallFinalize" (tried both Before or After). A repair gets the files installed. I finally set it to RemoveExistingProducts After="InstallInitialize" and that solved the problem but I am still wondering why the update didn't work. The files in the upgrade all had newer time stamps but some had the same version number although some did have newer version numbers. Is this a component GUID mismatch problem? If so how can I get around it? The Visual Studio version of the installer sequences the remove step just before the finalize step and I wanted to continue to do that. I am installing VC merge modules and their remove step follows the finalize step. Best Regards Paul ---------------------------------------------------------------------------- -- 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
