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? -----Original Message----- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Saturday, September 19, 2009 9:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? "The Component Rules" seem to be nearly impossible to follow. Assuming I understand them (a significant assumption), the only way to follow them that I can see is to not allow users to choose an install folder (since the rules say that every component must only install to one specific path - presumably so the KeyPath can be checked) and put every file in its own component, which is not really required, but if there is ever a chance in the future of files being added or removed to a component bad things can happen. So it seems to be the only defence given I don't have a time machine to find out how the component might need to change in the future. Those restrictions don't seem practical for any non-trivial real-world installer. I'm beginning to think that a Major Upgrade install and any other upgrade or patching is simply not going to happen. (And I suspect that following the component rules strictly will make MSI installs even slower, which won't go over well.) Even if I could follow the component rules to the letter for my version 2 installer, I obviously can't "fix" the installer that is already out there for version 1 to follow the component rules more strictly. I guess the next step is to come up with a setup.exe that will just do the uninstall prior to invoking the new installer. Are there any other options? I'm hoping I simply don't understand the component rules and they aren't as unreasonable as I have been lead to believe. Thanks, Scott On 2009-09-19, at 11:10 PM, Blair wrote: > 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
