So it's a bug in Windows Installer - since it is doing two deletes of the original file, one in a moved location and one in the original location. It could cross-reference with the pending-delete list (always, or even just when it decides that it has to move the original out of the way).
Obviously I can't wait for Microsoft to fix it. But following the component rules is a tremendous burden (I am dealing with around 900 files, not counting the merge module). I understand why they are the way they are, but it's still hard to manage. WiX installs are already extremely verbose and difficult to maintain. The component rules are so easy to break and there aren't good automated checks and balances. It would really like to see some tools to help in that regard. As I mentioned a tool that could check to see if rules were broken between v1.msi and v2.msi should be possible and would help a great deal. I'm going to see if I can educate the rest of the developers about the component rules. (Why does everyone hate doing installers?) - I'm just so scared that I'm going to screw up the rules and it will go unnoticed until it causes problems for a few customers. Testing every possible upgrade senario is something we just don't have resources for. What are the down sides to re-generating component GUIDs for every component for every build of the installer? If I will always be doing Major upgrades, will I still have problems? Does WiX/MSI have any facility for finding and terminating a process before continuing with the install? Scott On Fri, Oct 2, 2009 at 5:07 PM, Blair <os...@live.com> wrote: > 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 > > ------------------------------------------------------------------------------ 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
