I was also under the impression that FileVersion did *not* contribute to the naming attributes for a cached assembly. That is the reason I asked.
Phil, you seem to be suggesting that we can also get good behavior (as it relates to assembly versioning/naming) if we schedule RemoveExistingProducts just before InstallFinalize. Did I understand you correctly? Where does the MajorUpgrade element schedule RemoveExistingProducts? 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 > -----Original Message----- > From: Wilson, Phil [mailto:phil.wil...@invensys.com] > Sent: Wednesday, April 06, 2011 2:30 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] GAC File Update > > 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 > > P 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&pr > ev_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 ------------------------------------------------------------------------------ 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
