How'd anyone even know that was there?!? Let alone to search it with the COM browser?

Ah! Here's one of those basic knowledge items! That a CLSID is "created for a particular application when it's first developed"... I didn't have a clue..
Then also, Logic would have me conclude that I should be generating a CLSID for each of the apps I develop, too?..
Then also, Logic would have me conclude that I should be generating a CLSID for each of the apps I develop, too?..

Seriously, I think that you will only need to generate GUID /CLSIDs for your apps when you start to write Com Components.
Some notes mostly cut from PB's help files that might help clarify:
A COM Component is generally known as a COM SERVER, because it serves up information or actions requested by a COM CLIENT. A COM SERVER is a special form of code library (embedded in a dll/ocx/exe file) that conforms to the COM specification. It provides at least one public interface, and is identified by a globally unique CLSID so that it's Methods and Properties can be made public and a COM CLIENT can call them as needed.
It's own CLSID identifier is stored in the Windows Registry for each COM Component when it is installed and registered. (e.g. by calling, regsvr32.exe "MyComServer.dll"). Additional info is stored along with the CLSID - including a key called "LocalServer32", which holds the actual path\filename of the server application.
It's own CLSID identifier is stored in the Windows Registry for each COM Component when it is installed and registered. (e.g. by calling, regsvr32.exe "MyComServer.dll"). Additional info is stored along with the CLSID - including a key called "LocalServer32", which holds the actual path\filename of the server application.
Leave a comment: