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
- :
- Help! Com components registered in double!
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
‎Sep 27, 2010
01:49 PM
Help! Com components registered in double!
HELP!
When doing a minor upgrade, our new COM components are installed and registered, but the old versions are not unregistered before doing so! This results in double entries in the registry for each COM components and crashes our application with errors 430's!!!
Is there any way to unregister a COM component before it's updated?
Our installation package is a "Basic MSI" project, built w. IS2010 Premier Edition. Our self-reg files are included via Dynamic Linked folders, using the "Self-reg" option and "Create best practices" options. The previous kit's location is specified both as a Minor upgrade item and in the Release/build tab.
If the only way to go about this is the use a "major upgrade", this could be a show-stopper for us....
When doing a minor upgrade, our new COM components are installed and registered, but the old versions are not unregistered before doing so! This results in double entries in the registry for each COM components and crashes our application with errors 430's!!!
Is there any way to unregister a COM component before it's updated?
Our installation package is a "Basic MSI" project, built w. IS2010 Premier Edition. Our self-reg files are included via Dynamic Linked folders, using the "Self-reg" option and "Create best practices" options. The previous kit's location is specified both as a Minor upgrade item and in the Release/build tab.
If the only way to go about this is the use a "major upgrade", this could be a show-stopper for us....
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2010
02:42 PM
Well, we had to use a Major Upgrade and that solved the double registration of COM components, but it's clearly not the ideal scenario.
Does anyone know of a way to unregister COM components before they are upgraded in a Minor Upgrade scenario?
TIA
Does anyone know of a way to unregister COM components before they are upgraded in a Minor Upgrade scenario?
TIA
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2010
12:58 PM
"Our self-reg files" I assume that you are using the self registration setting for your file(s). This can be part of the issue as the self registration is not the best way to register COM objects. It is basically running the file that you have marks for registration with the /regserver or if it is a DLL regsvr32 after it is installed on the target system. However, this will work in the short term, but you will have to write custom scripts to unregister the exe or dll etc... prior to an uninstall because the changes made to the registry during the self registration will not be removed during an uninstall.
If you follow the best practice you should set the COM to be extracted at build time, this is helpful if the interface changes often. Or you can extract the COM once manually and have it stored in the Advanced Setting of the component. This also make it possible to remove the COM registration items from the registry during the uninstall process.
Side note on Coding standards.
If your COM interface is changing then the component that contains the COM server should have its GUID updated as it is literly not the same item. It should not be considered the same assemble if the COM interfaces have been modified so that backwords combatibility is no longer functional. Saying that, if a Feature or component is changed or removed as it would be in this case then you can't actually do an patch, or minor update, but will have to do a major update because components have changed, been deleted. So it would appear that InstallShield is following Microsofts Best practice models even if your developers are not.
I would push for a tighter adhearance to COM programming practices where the interface is not allowed to change once it has been published.;)
If you follow the best practice you should set the COM to be extracted at build time, this is helpful if the interface changes often. Or you can extract the COM once manually and have it stored in the Advanced Setting of the component. This also make it possible to remove the COM registration items from the registry during the uninstall process.
Side note on Coding standards.
If your COM interface is changing then the component that contains the COM server should have its GUID updated as it is literly not the same item. It should not be considered the same assemble if the COM interfaces have been modified so that backwords combatibility is no longer functional. Saying that, if a Feature or component is changed or removed as it would be in this case then you can't actually do an patch, or minor update, but will have to do a major update because components have changed, been deleted. So it would appear that InstallShield is following Microsofts Best practice models even if your developers are not.
I would push for a tighter adhearance to COM programming practices where the interface is not allowed to change once it has been published.;)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2010
03:49 PM
Actually, our COM components do unregister themselves when uninstalling - there is no trace of them left in the registry after the uninstall.
As for the COM-extract best practice, this can only be done for the Key file; our files are added using a Dynamic Link (w. best practices), so this solution is not feasible for us. Also, the COM-extract process results in registry entries that are somewhat different than the component's self-registration process: the COM component is usable by programs but "invisible" for referencing in VB6 or searching through our registry utility.
As for coding standards, our COM components are all "Binary Compatible", and we never break an interface. Adding new methods/properties to an existing interface does not break it, it just "versions up" and remains fully backward compatible with every program that used the previous versions. Said previous programs can use the new version without even being recompiled. If you *change* and existing method or property signature, then you are breaking the interface and are indeed creating a 'new' component', thus requiring a new GUID.
You really should not just lightly assume we don't know how COM works, nor imply we're not using best practices.
As for the COM-extract best practice, this can only be done for the Key file; our files are added using a Dynamic Link (w. best practices), so this solution is not feasible for us. Also, the COM-extract process results in registry entries that are somewhat different than the component's self-registration process: the COM component is usable by programs but "invisible" for referencing in VB6 or searching through our registry utility.
As for coding standards, our COM components are all "Binary Compatible", and we never break an interface. Adding new methods/properties to an existing interface does not break it, it just "versions up" and remains fully backward compatible with every program that used the previous versions. Said previous programs can use the new version without even being recompiled. If you *change* and existing method or property signature, then you are breaking the interface and are indeed creating a 'new' component', thus requiring a new GUID.
You really should not just lightly assume we don't know how COM works, nor imply we're not using best practices.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)