Connect to remote COM object

[knuckle05]

Hi All,

I have created a COM activeX .exe component that I need to install on one Win XP machine and then have all my other client PC's use this one component from the server machine.

So, I understand that I would need to configure DCOM to make this all happen, but I'm having a really tough time with it.

I am not using Windows NT or Win Server or anything like that, just a normal Win XP box acting as my "server".

From Component Services on my server machine I am able to see my component, and configure the properties.

I'm just very unclear on this point: Once my COM component is installed on my server machine, how will all my client applications know to connect to this machine instead of looking for the component locally, since it won't be installed locally?

Can someone help me out here, I'm about to lose my mind...thx!

Any help would be greatly appreciated....

 

[LazyMe]

You can use DCOMCNFG on the client computers for that.

Greetings,
Rick

 

[knuckle05]

Ok, but how will dcomcnfg see the object installed on the remote PC?

I'm running in a peer to peer fashion, and do not have MTS or anything to create a package.

Any ideas?

 

[LazyMe]

>>Ok, but how will dcomcnfg see the object installed on the remote PC?

It won't; you'll have to at least register the typelibrary of the remote component on the client machines as well. With DCOMCNFG you can then redirect the COM calls to a remote machine.

Greetings,
Rick

 

[knuckle05]

>>It won't; you'll have to at least register the typelibrary

Ok, does this mean if I include this .exe server object as part of my installation package created through the VB Package and Deployment wizard that I can configure it through DCOM and just tell it to run on the remote machine?

What exactly do you mean by type library?

I appreciate your answer, and it is a good one, but this may become a real pain, having to configure DCOM on every client machine.

Do you think this is possible? :

When instantiating the object through code by using the command:

CreateObject ("myObject.myClass", [Server])

there is an optional parameter for specifying the server. Do you have any experience with this?

 

[LazyMe]

>>Ok, does this mean if I include this .exe server object as part of my installation package created through the VB Package and Deployment wizard that I can configure it through DCOM and just tell it to run on the remote machine?

YES!! That's exactly what you can do then.


>>What exactly do you mean by type library?

The typelibrary describes the interfaces and objects etc. in your COM server. It is embedded into the EXE.


>>CreateObject ("myObject.myClass", [Server])

Never done it, but don't see any problems using that. It will even be more flexible, since you can specify the remote machine name on the fly.
Mind you: you'll still have to register the typelib, even when using the CreateObject() extension.


You can also create a registry script to be executed after the installation on the client, which will create the registry entries that would otherwise be created by DCOMCNFG "manually".

Greetings,
Rick

 

[knuckle05]

Nice!!

Could you point me in the right direction on creating the registry script?

BTW, you may possibly be a genius...

 

[LazyMe]

Well, actually I don't remember by heart the entries made by DCOMCNFG. You'll have to have some pacience, because I'm at work now and don't have the papers here that say which entries are necessary.

You'll still need to get to know how to use DCOMCNFG, though, since you might need to set security and permissions and such on the server.

Greetings,
Rick

 

[SemperFiDownUnda]

knuckle05 - you should really get used to using DCOMCNFG.
Why? If you don't understand how to do it via DCOMCNFG the registry entries are not going to make much sense and there is more chance of you missing a needed entry.

 

[knuckle05]

Hi,

Actually today I succeeded in running my component remotely on another machine, I used DCOMCNFG to configure the component on both the client side and server side.

It works, however, I have a few Q's.

Do you absolutely have to install the component and register it on the client side? It doesn't amke sense to me that you would since you will never actually be using it on the client side, you'll just be sending a message to the server to instantiate the server object and perform the task.

Still, I will have many PC's to install this on, so an automatic DCOMCNFG script to manipulate the registry would really come in handy.

I've never done this before though, does anyone know of a good resource for getting started, or an example if it's relatively easy?

thx!

 

[SemperFiDownUnda]

Technically no you don't have to register the DLL on the client machine. All that needs to be done on the client machine is for the interface to be registered on the client machine. The problem is VB embeds this info IN the DLL and does not provide any other mechanism to have a TLI file.

Either way if your trying to find a way not to goto every machine you are out of luck because you have to register the interface.

If you use late binding you can get away without doing this but that means your code will run slower for the extra call that is made for every call in your client app.

 

[knuckle05]

Actually I can't use late binding because my component uses callbacks to the client so I have to Dim my object WithEvents.

I didnt actually try late binding but figure it wont compile properly because I need to have the reference to the object.

thx!

 

[SemperFiDownUnda]

correct the sinks on the com object won't allow late binding....well they will just won't get the events fired back.

So you'll have to regester the components. Sorry.
Look at using some login script to do it if you don't have SMS server or other application distribution mechanism in place.



Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first

 

[almoes]

You deployed your server component in VB right? then you only need the .tlb and .vbr files that were created when compiling your object. Along with the API CLIREG32 that comes along with VisualBasic you only need to paste these files in the client and run a bat file with the following command: clireg32 myServerComponent.vbr -t myServerComponent.tlb -s IPServer -d.
You could have the client download these files from the server via web download, for example.

cheers,
alej

 

[SemperFiDownUnda]

Good point Almoes. But I personally don't see the difference from registering the visual basic registration file and the type library files and registering the actual component which does this too.

In any case you HAVE to register the interface on every client that want to use it (for early binding)

There are many ways to get it registered on a machine but still hase to be done.

Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first