Thank you for the information, Phil. This raises another bunch of questions:
Why is the default in this location in the sequence (that seems unfortunate, since rollbacks are part of the point of using MSIs)? Should I change the location for all my installers? What's a good way to this when building the package? If I change nothing but add an InstallExecuteSequenceElement with a RemoveExistingProducts with a Sequence attribute of, say, 1501, will I be ok? Or do I have to use a complete other sequence (i.e., fill in all the values for all the other steps which might occur "manually")? (I looked at Nick Ramirez's book for 3.0, and this doesn't seem to be covered.) Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -----Original Message----- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: August-21-13 4:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Expected behaviour When REP is at that location, it's essentially a complete uninstall of the older product followed by the install of the new product, so what you get is very similar to a user uninstall of the old product and then the install of the new. The older files will be installed because you're basically doing a fresh install of the new product containing older files. Other locations of REP aren't all like that. Your problem is that REP needs to be after InstallInitialize because the rollback transation boundaries are InstallInitialize and InstallFinalize, so your REP was not in the transaction and not rolled back. Phil Wilson On Wed, Aug 21, 2013 at 12:04 PM, <keith.doug...@statcan.gc.ca> wrote: > Thanks for answering Phil, > > Unfortunately a verbose log is not available. However, I know that > there's no explicit sequencing of RemoveExistingProducts or anything > else for that matter by my WXS. According to the MSI itself it is > 1401, immediately after InstallValidate and before InstallInitialize > (I assume the sequence is just in ascending order of Sequence in the > InstallExecuteSequence table.) > > (If it matters, the whole is > FindRelatedProducts,AppSearch,LaunchConditions,ValiadateProductID,Cost > Initialize,FileCost,CostFinalize,MigrateFeatureStates,InstallValidate, > RemoveExistingProducts,InstallInitialize,ProcessComponents,UnpublishFe > atures,StopServices,DeleteServices,RemoveFiles,InstallFiles,InstallSer > vices,StartServices,RegisterUser,RegisterProduct,PublishFeatures,Publi > shProduct,InstallFinalize.) > > > Keith Douglas > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 > Facsimile | Télécopieur 613-951-1966 Government of Canada | > Gouvernement du Canada > > > -----Original Message----- > From: Phil Wilson [mailto:phildgwil...@gmail.com] > Sent: August-21-13 2:43 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Expected behaviour > > A proper answer will depend on where you have sequenced > RemoveExistingProducts. > > A verbose log will tell you what happened. > > Phil Wilson > > > On Wed, Aug 21, 2013 at 10:25 AM, <keith.doug...@statcan.gc.ca> wrote: > > > If a service update (a MajorUpgrade of a service installation) fails > > for some reason, and a rollback to the previous version happens, > > what happens if the MSI for the rollback cannot be found? Would this > > leave no files from the first package in the installation directory? > > I guess I may have naïvely thought that the rollback would just use > > the directory as is. If that's the case, what caches a copy of MSIs > > in the system directory so we can use them in this situation? We'd > > like to keep a sensibly named version in our own installer directory > > on these machines so technicians can do the installation manually > > under certain circumstances and to interoperate with our file > > transfer mechanism > (details of no importances). > > > > I'm trying to figure out why an install of one of our services had > > the net effect of simply deleting the old files but repair (of the > > seemingly installed new package) restored the new ones. All I know > > is accidentally old versions of the executable and libraries were > > included > in the new MSI. > > > > Moreover, what is supposed to happen in general in a MajorUpgrade if > > the KeyPathed file is of a previous version than the one currently > installed? > > > > I take it in that case any CompanionFiles of that will "come along > > for the ride" regardless of what happens, correct? > > > > Thanks, > > > > > > Keith Douglas > > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 > > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A > > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 > > Facsimile | Télécopieur 613-951-1966 Government of Canada | > > Gouvernement du Canada > > > > > > > > > > -------------------------------------------------------------------- > > -- > > -------- Introducing Performance Central, a new site from > > SourceForge and AppDynamics. Performance Central is your source for > > news, insights, analysis and resources for efficient Application > > Performance Management. > > Visit us today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg > > .c lktrk _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ---------------------------------------------------------------------- > -------- Introducing Performance Central, a new site from SourceForge > and AppDynamics. Performance Central is your source for news, > insights, analysis and resources for efficient Application Performance > Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c > lktrk _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ---------------------------------------------------------------------- > -------- Introducing Performance Central, a new site from SourceForge > and AppDynamics. Performance Central is your source for news, > insights, analysis and resources for efficient Application Performance > Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c > lktrk _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
