If you are using the C/C++ runtime MSM modules, you must place the RemoveExistingProducts action either right before or right after InstallFinalize (if you put it right before, it must be (immediately) preceded by an InstallExecute or InstallExecuteAgain action). See http://msdn.microsoft.com/library/aa371197.aspx for the four positions that action can be in.
The last two positions described on that page are the positions that ARE NOT "in the area" of InstallInitialize, but they require strict obedience to the component rules. The first two positions ARE "in the area" and are not compatible with fusion (the technology used for both SxS and GAC). The runtime library MSMs use SxS, which is why they require the later sequencing of RemoveExistingProducts. Given that you are using the runtime library MSMs, I would recommend moving to the locations around InstallFinalize and making sure you are following the Component Rules. -----Original Message----- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Saturday, September 19, 2009 6:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? There is a single custom action to run a command line after the files required are installed. This command appears to work fine in the case where I am not uninstalling a previous product, though it doesn't matter much if it doesn't run. The common component I'm installing is a company-private copy of a Java 6 runtime and the custom action is running the command to create the "shared archive" after I have installed all the files. As mentioned below - I read specifically that <RemoveExistingProducts After="InstallValidate"> will not operate correctly for installers using VC 2005 runtime merge modules, which both installers do. I need to do more experiments, as I am not convinced that the behaviour is even consistent. Thanks, Scott On 2009-09-18, at 5:11 PM, Blair wrote: > Does the merge module supply/use any custom actions? > Would the missing files be related to anything placed in the GAC? > Does the merge module populate any rows in the MsiAssembly or > MsiAssemblyName tables? > > When they say "in the area" they are referring to the first two > sequencing > positions described on this page: > http://msdn.microsoft.com/en-us/library/aa371197.aspx (which is what > you > appear to be trying to achieve). > > You could try moving that action to After="InstallValidate" to see > if that > makes any difference. > > -----Original Message----- > From: Scott Palmer [mailto:swpal...@gmail.com] > Sent: Friday, September 18, 2009 1:26 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Major Upgrade install - why are files missing? > > I have made an installer that attempts to remove a previous version > of a > product before installing the new version.The installer runs and > appears to > remove old files and coy new ones... but it at the end of it all > there are > files missing. > > I have a merge module that installs a common component into "Program > Files\Company Name\commonThing" and the same merge module is used in > version > 1 and version 2 of my product. It is some files from the common > component(s) that are missing after installing version 2. > > I used the following blogs as reference for my major upgrade installer > > http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8- > major-upgrade.aspx > http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724! > 249.entry > > In particular I choose to schedule the RemoveExistingProducts action > to > emulate a full uninstall followed by an install. > > I have a comment in my code that I've copied from somewhere on the > interweb > that says: > > <!-- <RemoveExistingProducts After='InstallValidate'/> Don't do this > on > Vista for things that use VC 2005 merge modules --> > <!-- > When RemoveExistingProducts is sequenced in the > InstallInitialize area > you effectively get > an uninstall of the old product followed by an install of the new > product. All other things > being equal, this means that file versions and Component guids > are > irrelevant. > When sequenced in the InstallFinalize area the install of the new > product happens over the > old product, so file versioning rules apply to each file being > installed. Component guids > also matter because RemoveExistingProducts uses ref counting to > decide > whether to remove > the old files or just decrement the reference count. The > components in > the new install > (files and registry items) are effectively being shared with > those in > the new product, so > it's important to follow component rules. > If you want an upgrade to behave as if the user uninstalled the > old > product then installed > the new one, then sequence RemoveExistingProducts in the > InstallInitialize area. > --> > <RemoveExistingProducts After="InstallInitialize"/> > > > I realize now that I don't even now which 'side' of > InstallInitialize counts > as "in" the InstallInitialize area. Is it "before" or "after"? (It > seems > that both would be "outside" of the actual InstallInitialize of > course) > > In any case I don't want to get fancy, a complete uninstall/ > reinstall is all > I need, not some fancy "only change the bits that need changing" > thing that > is surely going to go wrong. I just want it to work. It doesn't. > I'm lost. > Please help. :-) > > My merge module for the common parts of course uses the same > component GUIDs > in both products and installs all files to the same paths. > > If I launch the version 2 installer again and choose to repair the > existing > install, then it clues in to the fact that files are missing and > installs > them. > > Thanks in advance, > > Scott ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
