Schedule RemoveExistingProducts around InstallFinalize instead of InstallInitialize.
Here is what happens: Remove-before-install: File Foo.ext (part of component Foo) cannot be removed because it is in use during RemoveFiles. Windows Installer adds it to the pending-delete list. It doesn't move it first because there are no other component instances referencing it (it hasn't processed the installation yet, since you scheduled the remove first). Later, the new file is written over the top of the old file. Since that file is still in use (presumably), the old one may be moved and the new location is added to the pending-delete list, and the new file is written in its place. Then when you reboot, both files are deleted (since both are in the list). Windows installer never associated the two files because there were never two component instances using the same file at the same time. Remove-after-install (requires following the component rules): File Foo.exe (part of component Foo) can't be overwritten because it is in use during InstallFiles. Windows Installer moves it and adds the moved location to the pending-delete list, then writes the new version of the file in the place where the old one was. Later, when RemoveExistingProducts runs, Windows Installer notes that a component scheduled for removal has another instance and the file is not touched. When you reboot, the old file is deleted, and the new one is right where you want it to be. The advise to place RemoveExistingProducts early is for those who cannot afford to follow the component rules rigorously because they are generating their installation file lists in their builds and they are dealing with 1000's of files. Generally all the rest of us should be able to author our file lists once, use stable component guids (and/or auto-generated ones), and place RemoveExistingProducts late (which is more efficient in several measures). -----Original Message----- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Friday, October 02, 2009 1:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? I have determined how to reproduce this problem.When the user runs the installer it is possible that part of the application is still running. That means there are files in use that the RemoveExisting task wants to remove. These are then scheduled to be deleted after a reboot. The problem is that the same files are needed by the (Major) upgrade. These are all files from the very same merge module - the merge module used by v1 and v2 is the very same file. If I refuse to reboot and run my application after the installer terminates, it works. If I then reboot, files are missing. MSI should know that the components from v2 match the components it wanted to remove from v1 and be smart about scheduling the deletion after a reboot. How can I solve this? Scott On Mon, Sep 21, 2009 at 2:02 PM, Blair <os...@live.com> wrote: > I would be interested in seeing the design of the merge module as well as > install logs. > > With my previous employer we designed and had written much of such a tool > (integrated into our evolving build system). I have plans to write such a > tool, if there is interest I could push it up in the list. > > -----Original Message----- > From: Scott Palmer [mailto:swpal...@gmail.com] > Sent: Monday, September 21, 2009 6:19 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Major Upgrade install - why are files missing? > > Getting back to the original problem. The files that were missing after my > major upgrade install were in a merge module that I created that was the > same in both products and therefore followed the component rules (since > there were no changes to the install path or content of any components). > Would the incorrect scheduling of the RemoveExistingProducts task affect > more than just the VC 2005 redistributables? > It's going to be a tremendous effort to educate all of the people on the > team about the component rules so they can properly update the WiX code for > the installer when they add new files to the project. There doesn't appear > to be any good way to verify that the rules are being followed either. Is > there a tool that can compare my .msi files (V1.msi vs. V2.msi) and warn me > about possible violations to the component rules? I would think that > component guids could be compared between the two msi files and if the > number of files in a component or the install path has changed detailed > warnings could be shown. > > Thanks for your help, > > Scott > > > > On Sun, Sep 20, 2009 at 11:32 AM, Blair <os...@live.com> wrote: > > > It isn't that bad. The rules are intended to keep your architecture > stable > > from build to build and release to release (which is why you should only > > (re)generate component guids during builds in limited scenarios, in all > > other cases you should write once/don't touch except for the few changes > > that really exist). The problem with breaking the component rules lies in > > two basic assumptions on the part of Windows Installer: 1) a component is > > an > > atomic unit of installation (all or nothing always), and 2) there is a > > one-to-one relationship between a component's guid (it's "unique" name) > and > > it's "physical state" (the keypath's presence and other identifying marks > > such as version). > > > > Regarding component keypaths: you already do have a defined keypath > > hierarchy. Even though you allow the user to override the paths for > > specific > > nodes in your directory tree, pretend as though those overrides don't > exist > > and you will be fine as long as, for any given filename of a keypath, if > > you > > don't change its position in your non-overridden directory tree (and you > > didn't rename the nodes in that section of your directory tree) you > > basically just need to keep the guids stable. If you do change the > > directory > > the file is in and/or the filename, you will generally need to change the > > guid for that component. There is some "forgiveness" for file-based > > non-fusion keypaths: the keypaths are stored per-product for those > > components, so if you install a "shared" component between two different > > programs (even if one is an upgrade from the other) that part of the > > component will be treated correctly. > > > > Yes, you may find that already released versions of your installer didn't > > follow the rules the way you wish they had. If you don't change the > > composition your components, those components who's directory > > hierarchy/filename don't change should be left alone (keep things > stable). > > That should limit the trouble spots to those that files that are > > changing/swapping resources around. Cleanup your old violations during a > > time period when you don't have much churn in your inputs to your > packages. > > Go in stages on that cleanup (not all at once, generally). > > > > Yes, there are times when the rules will put you into a difficult place: > > one > > example is combining two COM files into one (and not changing the > > CLSIDs/ProgIDs). I have forced changes to groups of (COM CLSIDs/ProgIds) > > and > > (filenames and/or directories) all at the same time on occasion, and on > > other occasions I have had to ensure that I was reusing a retiring > > component's guid in a new component to ensure that the component didn't > > appear to disappear even though it saw a forced change to the keypath > (yes, > > sometimes we have to violate the rules, but each time please seek the > > advice > > of an expert to ensure there isn't a better way to get out of your jam). > In > > Windows Live Messenger, there is a scheme in place that allows us, via > > adding a row in the Upgrade table, to change the apparent location of the > > RemoveExistingProducts action (between early and late) during install > time. > > It is rarely used, but we have been forced to use it to "fix" some really > > sticky situations caused by releases to the public that were not vetted > by > > the setup group and/or really nasty changes to entire subsystems that > > conflicted with the component rules in really bad ways. Some component > > rules > > can be violated more easily/safely with major upgrades blazing the trail > > than others, so timing your fixes can help. And yes, we have on occasion > > written into our bootstrapper a "if we detect this, we send message XYZ > to > > the bootstrapper, and it will run a repair as soon as it completes a > > successful installation" routine before in some of our products. > > > > If you have a specific situation identified, please describe it with some > > detail and some of us may be able to help suggest a way out. Know that > the > > reason that it has taken years for heat.exe to reach the state it is in > > today is because it is so easy to hang yourself generating setup code > > inside > > your build. > > > > As to the installer's performance: I don't know how many files/components > > you have, but the wide variation we have seen in installation performance > > has more to do with the time that restore points take to generate and the > > sheer volume of file data that has to be uncompressed and written to disk > > than with any particular distribution strategy of files amongst > components. > > Have you profiled your setups to see where they are spending their time? > > <snipped excessive conversation history> > > > > ---------------------------------------------------------------------------- > -- > 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 > ---------------------------------------------------------------------------- -- 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
