Blair, Thank you for your reply.
Now I think I've got the clear notion of GAC and SxS, and how I should schedule RemoveExistingProducts. And it's okay with the product-level versioning issues. As for the component rules and the versioning rules of files, I'll check them out in "TAO of Windows Installer". Nobuo Kihara 2010/1/9 Blair <os...@live.com>: > 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 > ------------------------------------------------------------------------------ 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
