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
