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: Extraneous registry entries
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
Jun 01, 2012
02:09 PM
Extraneous registry entries
I am currently evaluating InstallShield 2012 Spring Professional edition and noticed some odd issues with the registry keys created during the installation of a C++ ATL component. For example, in the Registry section I have these entries:
[CODE]
[HKEY_CLASSES_ROOT\CLSID\{9F35E4D5-DCED-46FF-BE7F-08AB08EA5610}\InprocServer32]
@="[INSTALLDIR]TestExtension
ThreadingModel="Apartment"
[/CODE]
What I find confusing is that InstallShield is actually creating this in the registry and I have no idea where the extraneous InprocServer32 entry is coming from:
[CODE]
[HKEY_CLASSES_ROOT\CLSID\{9F35E4D5-DCED-46FF-BE7F-08AB08EA5610}\InprocServer32]
@="C:\Program Files\Company\TestExtension\TestExt.dll"
@ThreadingModel="Apartment"
@InprocServer32=hex(7): ... random Unicode gibberish ...
[/CODE]
In the entries that register the COM class names, I have
[CODE]
[HKEY_CLASSES_ROOT\TestExt.TestPropExt]
@="TestPropExt Class"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CurVer]
@="TestExt.TestPropExt.1"
[/CODE]
but it's actually creating these registry entries with an extraneous CLSID key:
[CODE]
[HKEY_CLASSES_ROOT\TestExt.TestPropExt]
@="TestPropExt Class"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CurVer]
@="TestExt.TestPropExt.1"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CLSID]
@="{35BFF5FF-FA9B-47CB-8C84-A20DD76E42ED}"
[/CODE]
This seems to be mostly harmless since the CLSID isn't used here and is actually fetched from the TestExt.TestPropExt.1 key.
I'm confused where these keys are coming from because they don't exist in the Registry table (looking at DirectView) or in the COM registration of my DLL.
[CODE]
[HKEY_CLASSES_ROOT\CLSID\{9F35E4D5-DCED-46FF-BE7F-08AB08EA5610}\InprocServer32]
@="[INSTALLDIR]TestExtension
ThreadingModel="Apartment"
[/CODE]
What I find confusing is that InstallShield is actually creating this in the registry and I have no idea where the extraneous InprocServer32 entry is coming from:
[CODE]
[HKEY_CLASSES_ROOT\CLSID\{9F35E4D5-DCED-46FF-BE7F-08AB08EA5610}\InprocServer32]
@="C:\Program Files\Company\TestExtension\TestExt.dll"
@ThreadingModel="Apartment"
@InprocServer32=hex(7): ... random Unicode gibberish ...
[/CODE]
In the entries that register the COM class names, I have
[CODE]
[HKEY_CLASSES_ROOT\TestExt.TestPropExt]
@="TestPropExt Class"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CurVer]
@="TestExt.TestPropExt.1"
[/CODE]
but it's actually creating these registry entries with an extraneous CLSID key:
[CODE]
[HKEY_CLASSES_ROOT\TestExt.TestPropExt]
@="TestPropExt Class"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CurVer]
@="TestExt.TestPropExt.1"
[HKEY_CLASSES_ROOT\TestExt.TestPropExt\CLSID]
@="{35BFF5FF-FA9B-47CB-8C84-A20DD76E42ED}"
[/CODE]
This seems to be mostly harmless since the CLSID isn't used here and is actually fetched from the TestExt.TestPropExt.1 key.
I'm confused where these keys are coming from because they don't exist in the Registry table (looking at DirectView) or in the COM registration of my DLL.
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 04, 2012
02:58 PM
I'm less certain on the CLSID in your latter example, but the random looking gibberish is what's called a Darwin Descriptor. It's used by Windows Installer to handle advertisement and resiliency, and is not reflected directly in the tables. I would suggest thinking of it as an implementation detail and not worrying about it.