• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

DCOM Question!!!

Hi, I am trying to learn DCOM using VB

I made very simple ActiveX EXE

below is my stupid server.

Public Sub Display(Message As String)

    MsgBox Message
End Sub

This is the only function that DCOM server has

below is my client code.

Private Sub Command1_Click()
   Dim a As DCom_Server.Class1

   Set a = CreateObject("DCom_Server.Class1", "grand-blue")
   a.Display "Hello"
End Sub

It works on the local machine, which named "grand-blue", but it does not work on a remote machine.

I get an error saying "Run Time Error 464,  Class not registered on local machine"

I added the reference of that class to my remote client machine from Project/References menu by browsing to "grand-blue" machine where the exe file exist.

I am using the BOOK called VB COM bu Thomas Lewis.  The book shows very simple client example like above and it does not explain how to use DCOM object from remot machine.

How do I make an instance of a class in a remote activex exe DCOM server using VB??
1 Solution
you must use "administrator tool\Com commponents" (I'm not sure which name it is) make a package in server, then distribute this package to client, an install this package in client use same tool.
because this tool is diffrent in diffrent Windowns version, so you need found it yourself, I can not explain detail.

In WinNT: Win NT 4.0 Option Pack\Microsoft Transaction Server\Transaction Server Explorer
You have to register your simple ActiveX EXE on both machine. On thing you have to set your simple ActiveX EXE
as binary compatability on Project->properties->component tab.

If it still doesn't work, you need to run dcomcnfg.exe on remote machine to allow 'specifiy user' to launch it.
It's actually a lot more complicated than that.  DCOM makes the registration issues very difficult, but let me try to explain.

When you compile your Server program on your local development machine, the registry gets a lot of entries that associate the GUIDs of your Server program with the actual EXE that contains them.  So, when the Client program does a CreateObject, the registry knows to go find that EXE and run it.

Now, when you want to install the Server Program on a remote machine, the Program has to be installed there in such a way as to make the proper registry entries there (so, you need to create an install program with something like the Package and Deployment Wizard and then "install" your server program on the server).  

Then, you will write your client program.  During development, if you use CreateObject, it will likely find the copy of the Server EXE that you compiled on your development machine.  That is fine for development.  However, when you build the installation program for your client program, you will need to tell the installation program that you want to use a Remote Component, and it will ask you to locate the .TLB file for that component (I think that is the extension).  This file was created when you built the install program for your Server EXE.

If all goes well, whenever you install the client program, you will be prompted for the name of the server where the Server EXE is installed and logon id to use when connecting to it.

Now, there is a slight shortcut.  When you are developing your client program, and you do the CreateObject and it finds the local version of your Server EXE, you can go into the registry and add or change a few of the entries so that it doesn't look on your local machine for the EXE but on a remote machine.  This will only work on a machine where you have either compiled the Server EXE or one where you have installed the Server EXE (because all of the registry entries will have been made).

I have a document somewhere that details the registry entries that you need to change, but I might have gotten them from the same book you have...

Now, after all of the registry entries are made/changed, and your client program can find the Server EXE on the remote machine, it still may not be able to run it!  That is because DCOM has a pretty complicated authentication scheme.

So, after all of the installs/registry entries are complete, then on both the Client computer and the Server computer you have to run the program called dcomcfg.EXE  Look through the list of components that it finds until you find your server EXE (it might only list it by the CLSID, so, you need to know what this is for your Server's Class)  Then, you can grant Execute permissions to the user you will be logging in as on your client computer.  Run dcomcfg on the client computer as well.

Now, after all of that, you may be discouraged with DCOM.  I encourage you to look towards using COM+ instead.  If your server is a Windows 2000 machine, then COM+ takes all of the headaches out of the registrations issues.  When you have your component installed and running under the W2K Component Manager, then you can export a .MSI file, and then take this .MSI file to any client computer (the client has to have the Windows Installer program installed), and just double-click on the .MSI file and it makes all the necessary registry entries.
string6Author Commented:
to mdougan;

God, your expaination was so detail.  Thank you very much.
I feel really bad that I can give you only 100 points.  Thats all I have now..........

Thank you very much again.
No problem.  Let me know if you have more trouble getting it to work.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now