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: Good way to test if COM dll is already registered
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
‎Feb 20, 2008
03:31 PM
Good way to test if COM dll is already registered
I have a COM question that I feel like I should know:( What's a good way to tell if any version of a dll has already been registered on a machine?
Basically, the big picture problem is that a colleague needs a dll to be registered on a target machine prior to an install. He can obviously install\register the dll automatically but doesn't want to do that if any version of the dll is already on the target machine. I suggested checking HKEY_CLASSES_ROOT\CLSID\{GUID} but is there a better way?
Basically, the big picture problem is that a colleague needs a dll to be registered on a target machine prior to an install. He can obviously install\register the dll automatically but doesn't want to do that if any version of the dll is already on the target machine. I suggested checking HKEY_CLASSES_ROOT\CLSID\{GUID} but is there a better way?
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 20, 2008
05:09 PM
Dave,
Apart from trying to load the COM class and catching an error, maybe look for HKCR\prog.id (where prog.id is whatever you'd pass to CoCreateObject)? The GUID would presumably change between versions, so if you want to check for any version, the version-independent ProgID might be the best...
Robert
Apart from trying to load the COM class and catching an error, maybe look for HKCR\prog.id (where prog.id is whatever you'd pass to CoCreateObject)? The GUID would presumably change between versions, so if you want to check for any version, the version-independent ProgID might be the best...
Robert
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 20, 2008
07:22 PM
Hi...and thanks Robert!
...I like your first idea of catching the error and I'll probably go with that.
...I like your first idea of catching the error and I'll probably go with that.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 20, 2008
11:00 PM
As an aside, this pattern is always a pain in the rear. You can jump through the hoops to do it right ( setup prereq probably ) or you can try to elminate the dependency or at least trade it for one you already have.
For example, I once had an install for a .NET 1.1 application that extended AppSearch by probing serial ports to detect a gate reader device and assign the com port to a property. Later the property was used for XML configuration data. This control had to be registered and hacked to allow calling it from script. All of this had to be done prior to the execute sequence.
Now days the .NET 1.1 application could be ported to .NET 2.0 and the SerialPort Class introduced in .NET 2.0 could be used via the supportfiles, comvisible wrapper class and DotNetCoCreateObject instead of the COM server.
Then again what do I know.... MC is evil, right?
For example, I once had an install for a .NET 1.1 application that extended AppSearch by probing serial ports to detect a gate reader device and assign the com port to a property. Later the property was used for XML configuration data. This control had to be registered and hacked to allow calling it from script. All of this had to be done prior to the execute sequence.
Now days the .NET 1.1 application could be ported to .NET 2.0 and the SerialPort Class introduced in .NET 2.0 could be used via the supportfiles, comvisible wrapper class and DotNetCoCreateObject instead of the COM server.
Then again what do I know.... MC is evil, right?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 25, 2008
05:21 PM
Hi Robert,
I am trying to check for prog.id=smiacore.session (Third party software) before installing our software
I have this key.
HKEY_CLASSES_ROOT\CLSID\{1E0AE031-8DE6-11d8-A869-0002A58642EC}\Prog.id
I am not sure this key will remain same for ever. {1E0AE031-8DE6-11d8-A869-0002A58642EC}.
So How can I check for prog.id
Thank you
Rajeev
I am trying to check for prog.id=smiacore.session (Third party software) before installing our software
I have this key.
HKEY_CLASSES_ROOT\CLSID\{1E0AE031-8DE6-11d8-A869-0002A58642EC}\Prog.id
I am not sure this key will remain same for ever. {1E0AE031-8DE6-11d8-A869-0002A58642EC}.
So How can I check for prog.id
Thank you
Rajeev
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 25, 2008
05:33 PM
Look in HKCR\Prog.ID .. for example,
HKCR\WindowsInstaller.Installer
But you'll notice the default registry value may be null. In that case, look at the CLSID subkey and check that it's default value has data.
Unfortunatly this is just a limitation of the AppSearch/Reglocator pattern. It can only check for registry values that are not null, it can't check for the existance of registry keys.
HKCR\WindowsInstaller.Installer
But you'll notice the default registry value may be null. In that case, look at the CLSID subkey and check that it's default value has data.
Unfortunatly this is just a limitation of the AppSearch/Reglocator pattern. It can only check for registry values that are not null, it can't check for the existance of registry keys.
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)