A CLSID should be a globally unique number—that is you should make sure that there are no other COM objects with the same ID! Microsoft provided a couple of utilities to generate CLSIDs. All these utilities rely on an algorithm capable of generating random and different numbers for any machine. The next figure shows one of these utility programs called guidgen.exe. It certainly comes with any version of Microsoft Visual C++ from 4.0 onwards.
Another command-line tool that does the same is uuidgen.exe. This isalso available through the same Visual C++ channel. This latter, however, has no user interface. Other non-Microsoft development environments allow you to generate a new CLSID within the IDE by just hitting a key combination. This is the case with Delphi 3, where—by pressing Ctrl-G—you can ask the program to create a CLSID for you.
A CLSID often is also referred to with the word GUID, which stands for Globally Unique IDentifier.
If you don't have any of these tools, then the Microsoft Scriptlet Wizard we examined earlier provides this capability. Any time you create a Server Scriptlet it returns a new CLSID.
Even if we are accustomed to seeing it as a series of numbers enclosed in curly brackets—and actually looking like a string—a CLSID is a number. It is, in fact, a 128-bit number with a variety of possible representations. The most frequently used is the one with curly brackets and dashes to isolate inner components. Something very much like this in fact:
{51eb18c0-98a7-11d1-83d1-f46705c10000}
You could avoid specifying a CLSID when creating the Server Scriptlet. In doing so, you're implicitly asking the registration code inside scrobj.dll to generate a CLSID for you when it's time to register a given Server Scriptlet. While this approach is perfectly legitimate, it has a subtle drawback. Your component, in fact, will not have the same CLSID on all client machines. Due to the internal machinery of the GUID generator, algorithms executing the program on different machines in different moment in times will surely produce different numbers. Naturally, this behavior is by design and not a bug.
On the other hand, having the same component registered differently on different machines is not necessarily a problem. This is, however, a potentially risky situation because some development tools may cache the CLSID of the COM components they're using and get confused if you register again.
Always remember that a CLSID unambiguously identifies a COM object, but it is just a number and its generation process has nothing to do with any aspect of the COM server file (name, size, date, or other).