On the rollback point, you still get rollback when RemoveExistingProdcts is after InstallFinalize, but probably not the rollback you'd like because it's outside of the transacted part of the operation. So the new product installs, transaction finishes, then the uninstall of the old product starts. If that fails it rolls back too - back to being installed again. Now you have both products installed on the system and a big mess on your hands. A better detour is to have a sequence InstallExecute, RemoveExistingProducts, InstallFinalize at the end because it still does the ref counting "detour" but is inside the transaction, so in the event of a failure to uninstall it rolls you back to having only the original product on the system.
The GAC issue is related to assembly identity (its naming attributes) and I don't believe file version matters in this particular case (it's not a standard naming attribute) and note that the kb article mentions changing AssemblyVersion as a detour, not file version. Caveat: I haven't tested whether changing File Version solves the problem, I just suspect it may not. That bug: Internally, "early" in the install Windows decides that the incoming assembly in the new MSI file is "identical" (the naming attributes) to the one that's already installed and decides not to install the new one. It doesn't bother to re-evaluate that decision even when RemoveExistingProducts removes it. Changing AssemblyVersion makes it different, changing strong name should, changing FileVersion "might", dunno. Has that been tested? Jacques maybe? Phil Wilson -----Original Message----- From: Jacques Eloff [mailto:repst...@gmail.com] Sent: Wednesday, April 06, 2011 11:40 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] GAC File Update The scheduling just depends on whether you want to perform a full uninstall/reinstall and whether or not you want rollback support. Scheduling after InstallInitialize does a full uninstall without rollback support - but others can correct me. The important thing is having the file version set. Also, by default, the MsiAssembly table won't have the file version information, only the assembly version, so you need to invoke light with the -fv switch to add this information On Wed, Apr 6, 2011 at 10:35 AM, Castro, Edwin G. (Hillsboro) < edwin.cas...@fiserv.com> wrote: > > Also, take a look at http://support.microsoft.com/kb/905238 > > > > If the assembly version remains the same, but the assembly file version > > changes, you will need to schedule RemoveExistingProducts after > > InstallIntialize > > The linked article contradicts the recommendation above to schedule > RemoveExistingProducts after InstallInitialize: > > Use a Windows Installer table-authoring tool to change the sequencing of > the RemoveExistingProducts action in the InstallExecuteSequence table to > occur after the InstallFinalize action. For example, use the Orca.exe > database table editor for creating or editing Windows Installer packages. > > After reading the article I understand why it recommends scheduling after > InstallFinalize. I do not understand why scheduling after InstallInitialize > accomplishes the same result. Can somebody explain? > > Edwin G. Castro > Software Developer - Staff > Digital Channels > Fiserv > Office: 503-746-0643 > Fax: 503-617-0291 > www.fiserv.com > Please consider the environment before printing this e-mail > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
