Just wondering - are you getting a FileVersion value in any of the MsiAssemblyName tables in any of these MSI files? I can't quite get my head around it, but in-place updates of a GACed assembly will happen when FileVersion is there, and if the GAC's location has moved then some parts of Windows Installer could get rather confused.
Phil Wilson -----Original Message----- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, October 19, 2011 1:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade It might be :) http://msdn.microsoft.com/en-us/library/aa367858%28v=VS.85%29.aspx "Action: FileAbsent Installer actually uninstalls component's files and leaves all other resources of the component installed." So the component as a whole is not being removed. A bit of digging turned up this post. http://community.flexerasoftware.com/showthread.php?t=126033 'I opened a case with Microsoft and eventually got to the bottom of my issue (shortcuts not deleting). First, here is what Microsoft had to say about the FileAbsent Action: "FileAbsent means that the files will be removed but the class registration (if any) and non-file resources will not be removed. It is caused when there are multiple products referencing the component GUID but each product has its own unique location for the files. The files for the product being uninstalled can be removed from their own product-specific location but the rest of the component resources (presumably shared) can not be removed because the other products still need them."' Not so strange in the normal case but with GACed files, the location should be the same in all MSIs. The GAC doesn't move around. So a few things to look at are: do you have the files in the same component in all installers ? The component definitions should be *exactly* the same in all: component guid and contents. If not, that might be the problem. If that's not the problem, are the components in the same place in the directory hierarchy in all installers ? I imagine that is what gives the "location" of the components, even though the files go in the GAC. That could matter if youre using * for the guid. -----Original Message----- From: Gregory Swanson [mailto:gswan...@athoc.com] Sent: 19 October 2011 02:37 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade I want to clarify what I was trying to say: after running the Major Upgrade and looking at the verbose log, under the RemoveExistingProducts action, I found a line for one of the old components that contains one of the v.3 Assemblies - it looks like Windows Installer is planning to remove it: MSI (s) (38:38) [17:05:07:710]: Component: component80; Installed: Local; Request: Absent; Action: FileAbsent; Client State: Local Thanks, Greg -----Original Message----- From: Gregory Swanson Sent: Tuesday, October 18, 2011 6:19 PM To: General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Replacing .Net v.3Assemblieswith.Net v.4Assembliesduring Major Upgrade We do have other applications that share some of these components, and that list is growing. But looking in the SharedDLLs key in the registry, I see that none of the .Net dlls are listed so I guess the SharedDLLRefCount attribute is not needed with .Net dlls. After running the Major Upgrade, the old package is removed from ARP. But the old .Net v.3 Assemblies are left behind in the v.2 GAC, while the new .Net v.4 Assemblies are in the v.4 GAC. Running an uninstall at this point removes everything. Under the RemoveExistingProducts action in the verbose log, I found a line for one of the old components that contains one of the v.3 Assemblies - it looks like Windows Installer is planning to remove it: MSI (s) (38:38) [17:05:07:710]: Component: component80; Installed: Local; Request: Absent; Action: FileAbsent; Client State: Local I don't expect that a single line from a 23 MB log file is much use though. Thanks, Greg -----Original Message----- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, October 18, 2011 11:42 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3Assemblieswith.Net v.4Assembliesduring Major Upgrade It might not be an issue, but just reading your code I'd tend to avoid the SharedDllRefCount. But, reading that also makes me wonder if there was a particular reason for using that? Do other packages you know of also deliver the same DLL? I'm not sure how to generate an uninstall log when the Major Upgrade is the one doing the uninstall of the prior package. Maybe the registry keys for voicewarmup? Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer Reg_SZ: Logging Value: voicewarmup The verbose log file will probably be the only way to see what is going on behind the scenes. You are sure that the Major Upgrade is removing the other package? Control Panel only shows the newest one when you are done installing it? -----Original Message----- From: Gregory Swanson [mailto:gswan...@athoc.com] Sent: Tuesday, October 18, 2011 11:28 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3 Assemblieswith.Net v.4Assembliesduring Major Upgrade They're installed using the Wix File element for .Net Assemblies, like this: <Component Id='component132' Guid='6B1A694F-5FAF-4CB8-9644-8F679DB58238' DiskId='1' SharedDllRefCount='yes' Location='local'> <File Id='NETf57' Assembly='.net' KeyPath='yes' Name='example.dll' Checksum='yes' Vital='yes' AssemblyManifest='NETf57' Source='IWS\ServerObjects\DOTNET\example.dll' /> </Component> -----Original Message----- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Tuesday, October 18, 2011 11:16 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3 Assemblies with.Net v.4Assembliesduring Major Upgrade How are the files being GAC'ed in the old installer? Custom action or using the File element attributes? -- John Merryweather Cooper Jack Henry & Associates, Inc. (Premier Tech, Inc.) Build & Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -----Original Message----- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, October 18, 2011 12:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3 Assemblies with .Net v.4Assembliesduring Major Upgrade That's very odd. The old MSI that installed those v.3 assemblies is the one that should be removing them, not the newer MSI. If you don't consider the upgrade, but just uninstall that older MSI through Control Panel does it not remove the GAC'ed files? The Major Upgrade simply uninstalls that previous package so no real extra mechanism is usually required. Sounds like an issue of some sort with that older MSI. You've probably done the best given the situation, but the real question is what caused the situation in the first place? We use lots of GAC'ed files and have not run into a given installer not uninstalling the GAC'ed files it is responsible for. -----Original Message----- From: Gregory Swanson [mailto:gswan...@athoc.com] Sent: Tuesday, October 18, 2011 10:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3 Assemblies with .Net v.4Assembliesduring Major Upgrade Follow up - I implemented a custom action that uses gacUtil.exe to uninstall the old assemblies and scheduled it just after CostFinalize in the InstallExecuteSequence. -----Original Message----- From: Gregory Swanson [mailto:gswan...@athoc.com] Sent: Thursday, October 13, 2011 3:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Replacing .Net v.3 Assemblies with .Net v.4 Assembliesduring Major Upgrade Hello: I have an MSI developed with WIX, which packages (among other things) a few .Net DLLs. Recently, these .Net v.3 DLLs have been updated to .Net v.4. I noticed that after running an upgrade, the .Net v.3 Assemblies remain in the .Net 2 GAC (I noticed this after upgrades on Windows Server 2003 R2 and Windows Server 2008 R2). What I don't understand is: since I am installing .Net v.4 Assemblies, should the .Net 3 Assemblies be removed by the MSI or not? The .Net v.4 Assemblies are installed in the .Net 4 GAC and the application seems to work fine, but I would like to remove the old v.3 Assemblies during upgrade. While investigating how to do this, I found a reference to Bob Arnson's blog ( http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/ ) and followed his advice by setting RemoveExistingProducts to execute Before InstallInitialize. It was set to After InstallFinalize previously. Checking the verbose log, I do see that RemoveExistingProducts now executes just before InstallInitialize, but the v.3 Assemblies were not removed. The DLLs are authored one per component. So I thought that maybe the scheduling of RemoveExistingProducts is not the reason, maybe something else like file versioning (we have a build engineer who manages that, and since the builds are automated I don't usually notice a problem right away). I checked the file versions, and one .Net v.3 DLL has a File Version of 2.3.0.0, while the .Net v.4 copy has a File Version of 2.10.0.0. The Assembly version is the same for both DLLs. I think this is the correct versioning to prevent a side-by-side deployment when the DLLs are created with the same, or even with different versions of .Net. I'm pretty sure I could remove the .Net v.3 Assemblies with a simple Custom Action, but I don't want to do that if there is a better approach. Thanks in advance for any help. Greg ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ 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/en/legal/default.aspx. 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). ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
