Registration

[aknisely]

Why the hell did MS do this? I have to register COMs constantly and its a huge pain in the ass!!! I seriously cannot understand why it is so hard to just call up the DLL or EXE that you want to use. Anyone offer enlightenment?

[$CCF$]

1) You can't just use the file because the methods, properties and events in the DLL, OCX or ActiveX EXE may be different to another version. For example, you may make a DLL with a "FetchDatabaseRecord" method. Later versions may take parameters with the method call, or the method may not exist at all. If your EXE program uses the ActiveX EXE/DLL/OCX and you change the method signatures (change function/sub names or parameters) then you must re-register the EXE/DLL/OCX file and re-reference your project. *This allows you to bind an EXE project to a particular DLL/EXE/OCX so that if you have multiple versions of it around your system or network, the correct one will be used."

2) Registration for COM really becomes useful in DCOM (Distrbuted COM). DCOM is nothing fancy. The GUID number of the DLL is put into the registry when registering. Also palced into the registry are class IDs (CLSID) to all classes belonging to the GUID (or DLL). This is in effect detailing what can be called from your DLL package. To show you why this is important in DCOM we need to look at an example.

Suppose you write a DLL and it contains the Business Logic for a company, it will be shared by everybody in the company worldwide, and is compiled on some kickass cuting-edge server at some location. Your PC cannot just load up objects off of the remote machine (you don't have jurisdiction over that machine in anyway). If you knew the program name alone and DCOM worked without GUIDs, the server would be available to anyone with the IP address. Anybody could make mass calls to methods of objects that occupied large amounts of server time and effectively shut down the services of the server to everybody else. Luckily, this can't happen because of registering.

You however, have software which can identify available classes, because in your compiled client application is a reference to the GUID on the remote machine which identifies the DLL and will get you access to creating objects on the server. Other's wont have this. The chances of someone selecting a usable GUID are virtually nil (so remote it's not funny). Now it looks kind of safe compared to just loading up a file with self-describing data doesn't it?

I will be the first to accept that registering can be a pain in the ass when making many changes and also leads to the famous "DLL HELL" syndrome. Visual Studio.NET will change that. I have some security concerns over .NET and especially the web-service side which uses Simple Object Access Protocol (SOAP) but that's another story.

HINT: To make Registering and Unregistering easier, you should make two shortcuts in your "Send To" folder. The first shortcut will run "Regsvr32.exe", the second will run "Regsvr32.exe -u". Now when you locate a DLL, you can right-click, select "Send To" and have a "REGISTER" and "UNREGISTER" option in your "Send To" menu. This will negate the need for you to ever type anything from the command line to register or unregister anything again!

HINT2: When you first make a DLL, you will build it on "Project Compatibility" under the "Component" tab of the project properties dialog. After your first complile, you should set this to "Binary Comapatibilty" to prevent new GUIDs being made for each compilation (otherwise you'll end up with lots of duplicate reference slots for your DLL in the references dialog). Binary Compatibility will force each subsequent compilation to use the GUID you first used.

$CCF$

[aknisely]

Still, there must be a better way... *strikes a post like The Thinker*