How does COM registration work in Windows

Question

I'm an application packager trying to make sense of how the COM registry keys (SelfReg) interrelate to the given .dll in Windows.

ProgID's, AppID's, TypeLibs, Extensions & Verbs are all tied around the CLSID right? Do CLSID's always use Prog/App IDs or could you just have a file extension class? Which bits are optional?

Some of it seems to be 'like a router' where there's the two interfaces (internal - .dll) and external (the extension etc).

How does this all fit? (The SDK documentation doesn't make sense to me)

I ask as this is all pivotal to application 'healing' with Windows Installer (which packagers are all 'big' on, but there's no nitty-gritty breakdowns since its a coder-thing really)

---Edit: Am I safe in assuming that for what COM is registered, it must all link back to the CLSID and cannot be a 'dead-end'? Verbs need extensions which need progid's...

What about the AppId's, TypeLibs and Interfaces? How do they interrelate?

Answer 1

The first thing to realise, is that COM dlls register themselves. They will put all the required entries into the correct places in the registry.

I think the answer to your central question about which bits are optional is probably that they are all optional for different types of objects. Automation objects require Prog/AppIDs if they are publicly creatable, but may not if they are only created internally, similarly a non- publicly creatable COM class can be listed.

Many COM objects that do not have automation interfaces (such as many of the COM classes microsoft uses internally in windows will not have any ProgId but will simply have an entry under their CLSID in HKCR\CLSID.

If I understand you correctly you are interested in this from a installer perspective. I would imagine that all you need do is ask the user to specify which dlls are selfregistering and then call

regsvr32 dllname.dll

or

exename.exe /Regserver

for a out of process server. If something goes wrong you just need to call the opposites.

regsvr32 /u dllname.dll

or

exename.exe /Unregserver

I hope that this answers your question.

Answer 2

I'd recommend the book Inside COM.

It wasn't the most up-to-date reference even during the COM heyday, but it's explains the basics quite well, including all the registry goo. Plus, I bet you can get a used copy real cheap.

I know this isn't an answer, but remembering what the chapter about the registry looked like - a non-specific "how does it work" question will require a really, really long answer...

Answer 3

I used an answer cos the comments seem so limited. Not sure how SO will interpret this (maybe I'll be deemed mad for talking to myself?)

"how does it work" question will require a really, really long answer

Thanks - what I'm trying to acheive is an understanding of that without actually being a developer - this is because of the way packagers attempt to group the COM registry keys with the .dll (in the same component) so that application resiliency works.

This means 'trapping' the COM from the .dll's registration and associating it in the correct advertising tables (CLSID, AppID ...ad nauseum) to the component that holds the .dll. Sometimes this isn't easy to see and sometimes (I'm told) it can break the app from functioning. I'm told that the COM doesn't need to be complete (self-referential).

I'm still trying to get my head around it all. Of course, if the packager captures all the information but doesn't associate the COM info to the .dll, the regkeys are still written at install-time, just the MSI doesn't baby-sit the application if things go wrong (which is almost never)

Answer 4

Answers to this question should give you what you need.