Hi all, I'm new to WiX and Windows Installer, just having walked through the lessons of WiX Tutorial. Now I'm wondering how I should plan the upgrading of the product. These are my questions:
1) Am I right to say that generally the major upgrade would be the best solution for relatively small product? The alternative methods have many drawbacks either for the users or for the developer. The small update and the minor upgrade are not very user friendly just with a raw MSI, and we have to provide a bootstrapper that wraps it. The patch also requires much more costs from the developer. On the other hand the major upgrade can be used both a initial installer and a upgrading installer just with a single MSI without any additional costs. The only possible drawback of it might be the size of the package in comparison with a patch. Right? 2) Where should I schedule RemoveExistingProducts? WiX tutorial doesn't include a sample source code for major upgrade, so I had to write my own. I noticed that I have to schedule RemoveExistingProducts in order to make a major upgrade package. According to the MSI SDK documentation, there are 4 possible positions in the sequence: (A) just before InstallInitialize, (B) just after InstallInitialize, (C) just before InstallFinalize, or (D) just after InstallFinalize. The documentation seems to recommend the last one for the sake of efficiency. But, Bob Arnson recommends (A) and (B) in his blog post(http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/) because they are much safer, and they are fairly efficient if you have followed the component rules. But, then again, I've read an article in MSDN (http://support.microsoft.com/kb/905238/en-us/) that says the early scheduling of RemoveExistingProducts might make a problem with assembly in GAC or SxS. Although I really don't have a clear understanding what GAC and SxS mean, they look something I can get rid of a touch with. But I'm not sure. So, what should I do? 3) There exists a downgrade prevention mechanism in Windows Installer not in the product level but in the component or file level. I'm thinking about the switchs of REINSTALLMODE. I think it is sometimes very confusing, because it works irrelevant of the versioning rule of the product level. When you apply a minor upgrade package of 1.0.1 to the existing 1.0.0 by the command line of "msiexec /i foo.msi REINSTALL=all REINSTALLMODE=vomus", it will work just fine. Just as you would have expected, foo.exe will be upgraded from 1.0.0 to 1.0.1. But after the upgrade, when you try to apply the wrong package of 1.0.0 to the existing 1.0.1 with the same command line, it will finish installation without any error or warning messages as if the downgrading has been completed without any problem. But in fact the foo.exe is protected by the "o" switch of REINSTALLMODE and will stay with the newer version of 1.0.1. It's true that I specified the "o" switch to prevent the downgrading, and the result must be the right one "by design", but I feel that it's still very confusing. All the more for the users who happened to have run the wrong package of minor upgrade from a bootstrapper where they were not responsible for the REINSTALLMODE switch. If you want to inform the users with some suitable messages regarding this downgrade prevention, you will have to provide some extra mechanism not in your MSI but in your bootstrapping wrapper. WiX tutorial suggests to use a "safety lock" using the Upgrade element to prevent the downgrade, but it doesn't work for this scenario, because FindRelatedProducts does nothing and returns immediately in the REINSTALL mode. Have I misunderstood something? Am I right? But it's okay, I gave up using small updates and minor upgrades for myself. The questions are: 4) Does the same kind of downgrade prevention mechanism exist for major upgrade scenario? 5) Does it consider the last modified date of the file when it has no version information? Or, do I have to protect the user configurable files that have been modified by the user after the installation, probably using a custom action considering the UPGRADINGPRODUCTCODE property as Gabor suggests? 6) And the last question is a vague one, because I don't have a clear understanding of the so-called "Component Rules". When should I change the GUID of a component? Am I supposed to change the GUID of the component when I add to or remove from a component of EXE file something like a shortcut? And what about the location of the file? Should it hold the same GUID if the file name remains the same? ... etc. Is there any good comprehensive explanation of it to refer to? Nobuo Kihara ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
