Also, Daniel, to attempt to help you answer your question as to the difference in behavior caused by the addition of the InstallExecute and the placement of MsiProvideAssembly, it helps to understand the following about Windows Installer:
Everything you see in any sequence table you should consider as running "immediate" (that is what allows the built-in actions to access the database and session values). Usually everything between InstallInitialize and InstallFinalize should eventually be "writing to the script" (which means either they are marked as some sort of deferred or attempt to "do" (or call) an action that is marked as deferred). There are three actions that will run/flush the script: InstallExecute, InstallExecuteAgain, and InstallFinalize. Whenever any of these are hit, Windows Installer runs the script that has built up via the previous actions. However, with the exception of InstallFinalize, they don't run any action marked as a "commit" action. That means that commit actions are ever only run once. Keep the above in mind while reviewing the docs on the built-in actions on MSDN. As an example, it is as if the built-in RemoveFiles action where really two "custom actions", one immediate (that you actually sequence) and one deferred (that you never see the definition of) that the immediate action "calls" to cause it to be written into the script. This means that using InstallExecute (and InstallExecuteAgain) allows you to "change" the dynamic caused by the timelag between when code can access the database and session variables and when it can change the system. That is also the pattern used by most of the WiX custom actions (an immediate custom action that you schedule, and a deferred action that the immediate action just calls). -----Original Message----- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: Tuesday, December 15, 2009 10:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question on updating GAC assemblies If you're doing a minor upgrade and want to replace the assembly in the GAC then ensuring there is an incremented FileVersion in the MsiAssemblyName table is the way to do it, without changing any other assembly name attributes. A major upgrade where RemoveExistingProducts is sequenced near "the end" follows file replacement rules because new files are installed (and guid ref counted) on top of existing files, and then ref counted down when the older product is uninstalled. That's why file overwrite rules matter in some major and all minor upgrades, and why Aaron's blog article is relevant. So keep everything the same, use FileVersion in MsiAssemblyName as in Aaron's blog, and do an in-place replacement of the assembly. A minor upgrade will not remove an assembly from the GAC. That's why you're seeing what you're seeing. Component rules have to be followed, so you can't remove a component from a minor upgrade, and if you change an assembly naming attribute it will look like you're installing another and you'll see both there in the GAC. The answer is not to fiddle with sequences until it works. If you want to change assembly naming attributes, give it a new component guid and do a major upgrade. If you want an in-place minor upgrade replace use FileVersion. Welcome to GAC hell. If you can avoid the GAC, then do! Phil Wilson -----Original Message----- From: daniel.roberts...@repab.se [mailto:daniel.roberts...@repab.se] Sent: Tuesday, December 15, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question on updating GAC assemblies Thanks for the reply. I've read that article but it's not quite the situation I have. We are not doing an major upgrade (not that I'm sure if that’s making any difference) and I don't want to do an in-place upgrade. From what I have read it's recommended to change the strong name. http://msdn.microsoft.com/en-us/library/aa372360(VS.85).aspx Actually I found out that when installing and upgrading one of our other products, which is much smaller in size but still uses the same core-files in the GAC, it all runs smoothly and the GAC get's correctly updated. And when searching the log files I found tsome differences in the install process Specifically, in the first product one Merge Module (MSM) had added InstallExecute action to the InstallExecuteSequcence which wasn't the case in the second, smaller, product. So inte the smaller product all the actions were carried out during InstallFinalize and it all looked good afterwards. Searching for references to the DLL in the larger product gives that the ComponentRegister and AssemblyCopy is carried out during InstallExecute, but the MsiPublishAssembly were scheduled afterwards so that it was carried out during InstallFinalize When I moved the MsiPublishAssembly to just before InstallExecute, then it solved the problem also with the first product. So that's fine. But since I don't quite understand why it helps, I'm not really sure if this is a good solution? After the InstallExecute(in the large install)/InstallFinalize(in the small one) there are some log rows refering to my Dll:s in the GAC. MSI (s) (04:C0) [07:37:25:597]: Entering MsiProvideAssembly. AssemblyName: Foo.Core,version="1.0.1000.0",culture="neutral",publicKeyToken="A49BFB72E69D05A4",processorArchitecture="MSIL", AppContext: , InstallMode: -4 MSI (s) (04:C0) [07:37:25:597]: Pathbuf: 0, pcchPathBuf: 0 MSI (s) (04:C0) [07:37:25:597]: MsiProvideAssembly is returning: 1607 MSI (s) (04:C0) [07:37:25:613]: Verifying accessibility of file: Foo.Core.dll MSI (s) (04:C0) [07:37:25:613]: Note: 1: 2318 2: C:\Config.Msi\2ef4398.rbf MSI (s) (04:C0) [07:37:25:613]: Using source file security for destination. MSI (s) (04:C0) [07:37:25:644]: Entering MsiProvideAssembly. AssemblyName: Foo.Core., Version=1.00.1000.0, Culture=neutral, PublicKeyToken=a49bfb72e69d05a4, processorArchitecture=MSIL, AppContext: , InstallMode: -4 MSI (s) (04:C0) [07:37:25:644]: Pathbuf: 0, pcchPathBuf: 0 MSI (s) (04:C0) [07:37:25:659]: MsiProvideAssembly is returning: 1607 Now, when successfully updating the GAC, this comes after the MsiPublishAssembly, and since it refers to the old Assembly version (1.00.1000.0) it looks like it fails. When I didn't succeed to update the GAC a couple of rows very similar to these were there after InstallExecute but before MsiPublishAssembly. Then the MsiProvideAssembly returned a value of 0 for success. I suppose this must have something to do with it. So what does MsiProvideAssembly do in this context and which action in the InstallExecuteSequence causes it to be run here? I believe it might be something with the Assembly binding? And of course, Is it an ok solution to put MsiPublishAssembly before this point or are there other ways to go? Regards Daniel -----Original Message----- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: den 10 december 2009 23:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question on updating GAC assemblies Something here on that: http://blogs.msdn.com/astebner/archive/2008/08/10/8847259.aspx and you should keep the assembly name values the same (so don't change the strong name). Phil Wilson -----Original Message----- From: DanR [mailto:daniel.roberts...@repab.se] Sent: Thursday, December 10, 2009 9:36 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question on updating GAC assemblies We develop multiple applications using the same framwork, hence we put some DLL files in the GAC. Now I’m trying to patch an assembly in the GAC to a new version. I’m giving it a new strong name by increasing the build number and are then updating my application by reinstalling the MSI (minor upgrade) with the new assembly in it. So fooCore.dll is increased from version 1.0.0.0 => 1.0.1.0 After the upgrade both the old and the new version of the fooCore.dll assembly are placed in the GAC. When does the old assembly gets removed from the GAC? Does it ever? Since, on this particular test-computer, I have but one of our products installed, hence no other product is using/referencing version 1.0.0.0 of the fooCore.dll. Shouldn’t that one then be removed automaticly during the upgrade? Of course, if there were other products using fooCore.dll I understand why the first version would still be there, but now the 1.0.1.0 version is the only one in use. regards Daniel -- View this message in context: http://n2.nabble.com/Question-on-updating-GAC-assemblies-tp4146652p4146652.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ 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 Portland House, Bressenden Place, London, SW1E 5BF (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 7821 3848 or e-mail inet.hqhelpd...@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). ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ 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 Portland House, Bressenden Place, London, SW1E 5BF (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 7821 3848 or e-mail inet.hqhelpd...@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). ------------------------------------------------------------------------------ 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
