One way to help with the component rules is to have WiX (v3) autogenerate the component guids (use compone...@guid='*'), because it is the component's guid, not its id, that is used to identify the component between products.
If the keypath and its directory path stay the same, wix will always produce the same guid for that file. If a component is removed, that is OK in major upgrades (as long as all the resources associated with that component go away with it). If a component is added, that is ALWAYS OK. If you rename a file, the component guid changes (effectively removing the old component and adding a new component. If you rename a directory, all of the files in that directory become new components (the old ones going away). If you rename a file (or its directory) you need to change all of the other associated resources that are not the keypath (such as non-keypath registry (COM, etc.) values, etc.) so they are different. Don't move non-keypath resources from one component to another. Follow these rules and you will be following the component rules. The component removal is only "illegal" in non-major upgrades. The basic rule is to always associate resources with the file they "belong to" and to not rename files (except to move resources around). Note that the above doesn't prevent allowing the user to set installation paths at install time. The installation path isn't used in computing the component guids, it is the directory tree you build into the MSI. As to the buggy nature of the scenario you used, it is because Microsoft uses a relatively simple algorithm to manage components, and as Raymond Chen would tell you about supporting legacy uses, it would be very difficult for them to change it now. -----Original Message----- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Saturday, October 03, 2009 4:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? 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 ------------------------------------------------------------------------------ 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
