This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Installing dll to GAC and overwrite old one
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2008
04:15 PM
Installing dll to GAC and overwrite old one
Hi,
Im tring to install a .net dll to the GAC, by creating new compoenent and specifying the Destination property to "[GlobalAssemblyCache]", then go to files and add the dll file to the compoenent. After building and running the MSI package, the dll gets installed to GAC fine. However when I try to uninstall it, it fails claiming that "Its required by other applications". I noticed that happen because when installing it, it adds a registry key for it in the registery under "[HKEY_CLASSES_ROOT\Installer\assemblies], and unless I delete this regitry it wont un install. The question is how to prevent that from happening while running the package to install the dll, so I can un install it without the need for deleteing the added registry?
I tried to manipulate the Componenet properties "Shared" and "Disable Registry Reflection" with no success.
This problem is also preventing the installer to overwrite the old version of dll with the new one, even though the property "Never Overwrite" is set to NO, and in the GAC I will endup having the different versions installed.
Thanks for your help
Im tring to install a .net dll to the GAC, by creating new compoenent and specifying the Destination property to "[GlobalAssemblyCache]", then go to files and add the dll file to the compoenent. After building and running the MSI package, the dll gets installed to GAC fine. However when I try to uninstall it, it fails claiming that "Its required by other applications". I noticed that happen because when installing it, it adds a registry key for it in the registery under "[HKEY_CLASSES_ROOT\Installer\assemblies], and unless I delete this regitry it wont un install. The question is how to prevent that from happening while running the package to install the dll, so I can un install it without the need for deleteing the added registry?
I tried to manipulate the Componenet properties "Shared" and "Disable Registry Reflection" with no success.
This problem is also preventing the installer to overwrite the old version of dll with the new one, even though the property "Never Overwrite" is set to NO, and in the GAC I will endup having the different versions installed.
Thanks for your help
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 07, 2008
12:10 PM
hi,
Can Anyone help me with above post...Please??!!
Can Anyone help me with above post...Please??!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 07, 2008
03:43 PM
A verbose log file of the uninstall may provide some insight into why the assembly is not being removed. The most likely cause (assuming only one MSI package is involved and this happens on a clean machine) is that the assembly is being included and installed by two separate components in the same package. This breaks Windows Installer component rules and results in an incorrect reference count maintained by Windows Installer and Fusion (the OS component that MSI uses to perform installations of GAC assemblies). As a result, the incorrect reference count prevents the assembly from uninstalling.
If a verbose log does not provide any useful information, I would recommend looking through the built MSI package's File table to ensure the assembly is not present twice in two different components.
If a verbose log does not provide any useful information, I would recommend looking through the built MSI package's File table to ensure the assembly is not present twice in two different components.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2008
01:55 PM
Hi,
Thanks for the reply. I checked the verbose log , and I did not see any errors reported. However still my old version dll is not overwritten, instead the new version gets added to the GAC besides the old one. As I said before in the first post, the porblem happens because when installing the dll via component that has [GlobalAssemblyCash] destination, it adds some key to the Registry. When I remove these keys from the registry, and try to run the installation, the newer version overwrite the old one as it should. So the big question is how to prevent InstallShield from adding these registry keys when installing the .net dlls ???
Appciate all the feedback.
Samer
Thanks for the reply. I checked the verbose log , and I did not see any errors reported. However still my old version dll is not overwritten, instead the new version gets added to the GAC besides the old one. As I said before in the first post, the porblem happens because when installing the dll via component that has [GlobalAssemblyCash] destination, it adds some key to the Registry. When I remove these keys from the registry, and try to run the installation, the newer version overwrite the old one as it should. So the big question is how to prevent InstallShield from adding these registry keys when installing the .net dlls ???
Appciate all the feedback.
Samer
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2008
02:53 PM
InstallShield does not write any registry keys under HKEY_CLASSES_ROOT\Installer. All information contained in this area of the registry is maintained by the Windows Installer service, including the Assemblies subkey (based on information contained in the MsiAssembly and MsiAssemblyName tables in an MSI package). Please see Assembly Registry Keys Written by Windows Installer for more information.
The fundamental issue remains that there is likely a problem with the way the MSI package was authored if this behavior occurs on any machine, including clean machines. We would recommend verifying the assembly is included in the MSI package in only one component, and validate the MSI package from Build->Validate->Full MSI Validation Suite in the InstallShield IDE to ensure no validation errors/warnings are reported about the assembly.
The fundamental issue remains that there is likely a problem with the way the MSI package was authored if this behavior occurs on any machine, including clean machines. We would recommend verifying the assembly is included in the MSI package in only one component, and validate the MSI package from Build->Validate->Full MSI Validation Suite in the InstallShield IDE to ensure no validation errors/warnings are reported about the assembly.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 08, 2008
06:08 PM
Hi Josh,
Thanks for the reply and patience.
I agree its a Windows Installer thing that causes it to store a value under the mentioned registry directory. I really exumed every possible way to find how can I change that, but no success. I did follow the instructions mentioned in in the following link http://support.microsoft.com/kb/892463, again no success. I'm very novice to this, and I would really appreciate it if you can direct me in what I need to do and where to go to prevent it from being added to the registry.
Again thanks for your help and appreciate it.
Thanks for the reply and patience.
I agree its a Windows Installer thing that causes it to store a value under the mentioned registry directory. I really exumed every possible way to find how can I change that, but no success. I did follow the instructions mentioned in in the following link http://support.microsoft.com/kb/892463, again no success. I'm very novice to this, and I would really appreciate it if you can direct me in what I need to do and where to go to prevent it from being added to the registry.
Again thanks for your help and appreciate it.