Inline... -----Original Message----- From: Kihara Nobuo [mailto:soft...@gmail.com] Sent: Friday, January 08, 2010 6:43 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Major Upgrade, RemoveExistingProducts, Downgrade Prevention and Component Guid
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? [Blair] Yes, you are 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? [Blair] The GAC is the global repository of .NET assemblies. SxS is a mechanism for installing multiple versions of the same COM services. If you are building or will build code that others will use (which includes extending the Windows Explorer shell, the Internet Explorer program, or extend other programs such as by creating Office add-ins) or even if you are distributing a driver you will probably need to be concerned with the GAC/SxS scheduling issue(s) and will need to strongly consider C or D. If your program is stand-alone (you don't export any functionality to other programs) and you don't have to install any runtime (except for possibly requiring some version of the .NET runtime), and that situation is likely to continue for a long time, you are probably perfectly safe using A or B. 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? [Blair] For those using only "Major Upgrades", you can use the Upgrade table and either a LaunchCondition or an Error custom action to prevent product-level downgrades without having to deal with REINSTALLMODE or any related mess. I'll show the pattern in answer to your #4. 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? [Blair] The product-level downgrade scenario for those who always let WiX generate the ProductCode (who set Product\Id='*' in their authoring) is a pattern similar to this: ... <?define UpgradeCode="INSERT-UPGRADE-GUID-HERE"/> <Product Id='*' UpgradeCode='$(var.UpgradeCode)'...> <Package .../> <Upgrade Id='$(var.UpgradeCode)'> <UpgradeVersion Maximum='$(var.Version)' Property='UPGRADEFROM'/> <UpgradeVersion Minimum='$(var.Version)' Property='DOWNGRADEFROM' OnlyDetect='yes'/> </Upgrade> <Condition Message='Attempted to downgrade [ProductName]. Not allowed.'>DOWNGRADEFROM</Condition> <InstallExecuteSequence> <RemoveExistingProducts After='PICK-YOUR-LOCATION-FOR-THIS-ACTION'/> </InstallExecuteSequence> </Product> ... 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? [Blair] This only applies to file/component-level up/down-grading concerns that minor upgrades and small updates are forced to use, not to product-version-level that major upgrades use. 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? [Blair] IMHO the best reference is the "TAO of Windows Installer". When I have a few more minutes I'll point you to other resources addressing the component rules as well. You can also search this list, entries by myself and several others address your direct questions. 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 ------------------------------------------------------------------------------ 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
