registering a com server

[Fred Harris]

So if you add a class to a pre-existing registered server, then the CLSID for that new class won't be in the registry, nor the ProgID. COM services ( SCM) won't be able to find it. It would be just like when you first compile a dll but don't have it registered yet.

However, if you were doing the LoadLibrary() / GetProcAddress() thing like we were playing with last week or so, you would be able to load it that way, and the CLSID is a parameter to DllGetClassObject(), so you would be 'in like flint'.

[jcfuller]

Thank You Bob!

James

[Bob Zale]

The only thing in the registry that really matters is the ProgID (Class name in PB) and the associated CLSID (GUID). Everything else is defined in the Type Library, not the registry.

Best regards,

Bob Zale
PowerBASIC Inc.

[jcfuller]

There's the gotcha. Are the problems I encounter during development server side or Client side?? I am aware of vtable order and don't believe that has anything to do with the registry. I just wanted to know what I can change in my server without having to do the un - re .

James

[Fred Harris]

That's a good question. I frequently add and move around debug code without unregistering/re-registering, but that doesn't really change anything critical. I think the answer depends somewhat on the type of access you are making, i.e., early bound / late bound or direct vtable access. Clearly, if you add a interface member, and you are doing early bound or direct vtable calls, that interface description will need to be forward declared and match what is in the dll or naturally you'll get a gpf pretty quick. My guess is that with direct access, if you recompile and call existing interfaces or methods, you won't need to re-register. Try and see.

[jcfuller]

Ok. thanks Fred. Why I'm asking is when do I actually have to unregister and then register again while I am developing a server. Do I have to if I add or remove methods and properties or only if I add or remove Class/Interfaces?

James

[Fred Harris]

It seems more standard though to register both a versioned and version independent ProgID. Also, the ProgIDs PowerBASIC puts in the registry don't exactly follow the standard convention of...

ServerName.CoClass.Version

This isn't an absolute requirement though, and if you search through the registry you'll find a lot of components that don't follow it. Most do though.

If you look at that CA component James that we were fooling around with a few weeks ago, and you still have it registered, you'll see what I mean. With that component I didn't register a type lib though - just a Clsid, a version independent ProgID, and a versioned ProgID.

The absolute bare minimum though if you want COM Services (SCM) to be able to load it though is a CLSID with a key holding the path to the dll/exe, and a ProgID holding the CLSID key. With only that info though (lacking a typelib entry & typelib), you'll only be able to access it through a vtable.

[Fred Harris]

In general, that depends on what code executes in DllRegisterServer. PowerBASIC seems to add this...

HKCR

\CLSID #######################
\InProcServer32 szPath
\ProgID


\ProgID szString
\CLSID ########################

\TypeLib
\various keys...
\etc

[jcfuller]

What actually is saved in the registry when your register a com server with regsvr32

James