COM files not registered... but really are?
We have a utility which compares our product's MSI install to current installed COM files so as to verify our applications running state.
To do this we read the COM HKCR hive obtaining each CLSID from the ProgID. For example MSComctlLib.Slider.2 is the ProgID of the Microsoft common control slider, and it's CLSID {F08DF954-8592-11D1-B16A-00C0F0283628}. Then we lookup the location of each COM file in HKCR\CLSID\InprocServer32 and store this path in a list.
We then use the COM path list above to compare against the "known" install manifest (for example from the MSI file) to ensure the COM version number and location haven't been moved. We do this because many COM 3rd party vendors don't obey the rules and break our application from time to time, so it's a Technical Support issue.
However, we have noticed that some COM's, ,especially for MS, don't obey the HKCR\ProgID\CLSID rule. However the files *are* COM's as they can be registered.
What are these?
Side note: I have noticed for one MSVBVM60.dll that it is in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\SelfReg\CLSID\
{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}\InProcServer32, but I need the CLSID to get to this InProcServer32 value and I cannot find it in the registry. Others like this are mfc40.dll, oleaut2.dll, etc.
Can any give me additional information as to why these components don't show in the registry as do other COM files?
[1511 byte] By [
D0nauld] at [2007-11-19 18:27:55]
# 1 Re: COM files not registered... but really are?
Can any give me additional information as to why these components don't show in the registry as do other COM files?There can be situations where the author of an application does not want to keep traces of a COM file in the registry. His application may be registering the libraries at start-time, and unregistering at exit-time.
Someone might want to ask - Why should such a person choose COM as a technology when his clients need to know the location of the server? One reason could be to enable cross-platform programming.
Another scenario I can think of is a tool that has backed-up a COM server... It would naturally not register the binaries in the backup location.
# 2 Re: COM files not registered... but really are?
We just looked at the merge module for our product, and it appears that the Microsoft supplied module for MSVBVB60 contains COM's that have not ProgID's.
I am assuming that since it has no ProgID, it won't appear in the HKCR list, correct? So... how do I determine if this particular COM is registered properly?
Thanks!
# 3 Re: COM files not registered... but really are?
how do I determine if this particular COM is registered properly?Use the return value of DllRegisterServer ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/4442206b-b2ad-47d7-8add-18002c44c5a2.asp) to verify registration success.
# 4 Re: COM files not registered... but really are?
Use the return value of DllRegisterServer (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/4442206b-b2ad-47d7-8add-18002c44c5a2.asp) to verify registration success.
My validation program operations only in "inspector" mode. (Remember my thread yesterday?)
The inspector component should not actively register any component. So I cannot register it to disover if it registered successfully. I need another method besides going down the ProgID list of HKCR.
Regards,
Don
# 5 Re: COM files not registered... but really are?
The inspector component should not actively register any component. So I cannot register it to disover if it registered successfully. I need another method besides going down the ProgID list of HKCR.Well... Prog Id even if present doesn't guarantee that a COM Server is correctly registered. The Prog Id corresponds to one COM class contained in the library at a time. Not more.
So, it is possible that of the 30 COM Classes present, the user has damaged 29, and you found the 30th one intact with Prog Id, et al.
Doesn't mean that the installed library is going to work all right.
Besides, Prog Id is particularly needed to work with automation clients. One can instantiate a COM object correctly without knowing the Prog Id, using the CLSID alone in non-automation clients like C++. Hence, it's presence is not absolutely essential.
# 6 Re: COM files not registered... but really are?
Well... Prog Id even if present doesn't guarantee that a COM Server is correctly registered. The Prog Id corresponds to one COM class contained in the library at a time. Not more.
So, it is possible that of the 30 COM Classes present, the user has damaged 29, and you found the 30th one intact with Prog Id, et al.
Doesn't mean that the installed library is going to work all right.
Besides, Prog Id is particularly needed to work with automation clients. One can instantiate a COM object correctly without knowing the Prog Id, using the CLSID alone in non-automation clients like C++. Hence, it's presence is not absolutely essential.
What I am doing is validating an MSI install where I know that a certain set of features should be installed and registered *are* actually present and accounted for in the registry. In most all cases the components that I register *do* have ProgIDs. I am looking for anomalies that suggest registration errors. But since some components don't have ProgID's, I am trying to determine if this is an error, or not, and report it so that my Technical Support staff can look at it a little more in depth when a customer calls and says X feature of my product doesn't work.
What you may be saying is that there is no way to do this, since it all hinges on the CLSID, and not the ProgID. That is I can run a registered component that contains on ProgID by just knowing the CLSID, hence it one appear in the ProgID list.
I am looking for a way to inspect further for objects that hve no ProgID's. Can I look at the COM file itself to obtain it's CLSID and then go from there? Yesterday you suggested a CALLBACK method using EnumResourceTypes for finding the typelib object, which worked wonderfully. Is something like that available?
Thanks. As before you have been a great help.
# 7 Re: COM files not registered... but really are?
OOPS. Clarify the above statement: That is I can run a registered component that contains *NO* ProgID by just knowing the CLSID
# 8 Re: COM files not registered... but really are?
Can I look at the COM file itself to obtain it's CLSID and then go from there?
No. A COM server needn't necessarily be self registering. Most often they are. A COM server, if self registering, is simply putting some registry entries. That's about it. And there is no fixed way to do this. If the COM server isn't self registering, instead relying on someone else to put all those registration entries, then again , the attempt is futile.
# 9 Re: COM files not registered... but really are?
What I am doing is validating an MSI install where I know that a certain set of features should be installed and registered *are* actually present and accounted for in the registry.I can assure you that so long as you are sure of the location and version of a Component you have installed and registered, it is safe to re-register the same if that suits your requirement.
In most all cases the components that I register *do* have ProgIDs. I am looking for anomalies that suggest registration errors. Why do you expect anomalies, and what problems are you looking for?
But since some components don't have ProgID's, I am trying to determine if this is an error, or notIt doesn't have to be an error. COM components can be shipped without Prog Ids... You have a problem only if a component was shipped with one that went missing. Again, why would this happen?
Registration failure should be captured at deployment time.
and report it so that my Technical Support staff can look at it a little more in depth when a customer calls and says X feature of my product doesn't work.Are you so sure that a mal-registered component will result in a single feature X not working?
It may even bring the entire product down.
Again, deployment either works fine, or it doesn't. There is no middle-way.
Yesterday you suggested a CALLBACK method using EnumResourceTypes for finding the typelib object, which worked wonderfully. Is something like that available?Unfortunately, no.
I am looking for a way to inspect further for objects that hve no ProgID's. Can I look at the COM file itself to obtain it's CLSID and then go from there? There exists a complicated method to non-intrusively check a COM Server for registration...
Typical Win32 COM modules (constructed using ATL) contain their registry entries as resources. You can actually individually scan each registry resource, and check for it's existence in the registry.
This is not only time consuming, but again - what is the guarantee that an accidently included registry resource never made it, and was never required. This would be reported as an error when in fact it wasn't one.
Bottomline - deployment either works, or it doesn't. It is important to capture errors at that stage. If you are sure of the files you registered - it is OK to re-register them.
# 10 Re: COM files not registered... but really are?
Typical Win32 COM modules (constructed using ATL) contain their registry entries as resources. You can actually individually scan each registry resource, and check for it's existence in the registry.
which is not a rule though... and again , all this only if the component is a self registering type.
# 11 Re: COM files not registered... but really are?
which is not a rule though... and again , all this only if the component is a self registering type.Which explains my usage of the word - typical. :)
