Personally, I'd just do the Major Upgrade with a clean install and call it good. The WiX toolset has 159 files and we do Major Upgrades all the time. It is easiest way to move from build to build. If the performance seems reasonable for your application, I'd recommend it. <smile/>
On Sun, Nov 8, 2009 at 10:05 AM, Paul Brook <pbr...@vaytek.com> wrote: > 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 > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ 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
