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
Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade
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
