Blair, Thanks for the explanation. Regarding your last paragraph about matching up GUIDs between installs.
"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." I am using "*" to generate the GUIDS in my WIX file. Obviously these are not matching the GUIDs created by Visual Studio in the Deployment Project .msi I am replacing, so I dumped the .msi using dark and realize I have a lot of typing to do to copy in each GUID. The question is this. Is it worth the effort to copy all the GUIDs into the new installer? Considering that doing uninstall early in the process cleanly uninstalls the old version and correctly installs the new one, what advantages are gained? I am installing around 80 to 100 files. At this point I am willing to do the RemoveExistingProducts After="InstallInitialize" as long as there are no problems lurking that will bite the process down the line. Thanks for help. Paul -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Saturday, November 07, 2009 6:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Is this a GUID matching problem - how to resolve. 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 ------------------------------------------------------------------------------ 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
