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
