Tom,
From what you said about your second RGS file, you may have a problem there. You said, "The second describes the exposed COM class. This second files has two distinct GUIDs. One serves as the CLSID for the exposed class. The other is used to identify the AppId and is also assigned as a value to 'TypeLib'. This AppId does match that contained in the other RGS file. "
What I find of concern here is that the same GUID is used to identify the AppID *AND* the TypeLib ... which, so far as I know, is invalid. Also, the AppID GUID should be specific to the DLL and not change from place to place. I am going to append an example from one of my EXE files ... edited a bit, of course:
HKCR
{
NoRemove AppID
{
{848375EF-****-****-****-***************} = s 'MyApp'
'MyApp.EXE'
{
val AppID = s {848375EF-****-****-****-***************}
}
}
}
HKCR
{
MyApp.1 = s 'MyApp Class'
{
CLSID = s '{848375FB-****-****-****-***************}'
}
MyApp= s 'MyApp Class'
{
CLSID = s '{848375FB-****-****-****-***************}'
CurVer = s 'MyApp.1'
}
NoRemove CLSID
{
ForceRemove {848375FB-****-****-****-***************}= s 'MyApp Class'
{
ProgID = s 'MyApp.1'
VersionIndependentProgID = s 'MyApp'
ForceRemove 'Programmable'
LocalServer32 = s '%MODULE%'
val AppID = s '{848375EF****-****-****-***************}'
'TypeLib' = s '{848375EE****-****-****-***************}'
}
}
}
The things to note here are that the AppID remains the same throughout, that it differs from the CLSID of the class objects (there are more of them), and that it differs from the TypeLib. The TypeLib should match the entry in the lirbray section of the IDL file. It will appear as uuid(<TypeLib>).
The IDL is a better source for the TypeLib than the RGS files ... I have seen several instances where the incorrect TypeLib (or even several different instances of incorrect TypeLib GUID's) appear in RGS files, and they don't appear in the IDL. Once all the entries match, there is generally little difficulty getting things to register.
The way we confirm the registry information for a file that has the SelfRegister entry point is to use a LoadLibrary call followed by reading the resource string table. Then we identify those resource blocks that are identified as Registry information (or look for HKCR ...) and then parse the strings to recover imbedded registry data.
If this sounds as though it is on the right track, and you need more specific details, please feel free to drop me an email, and we can get down to cases.