Re: Stupid ATL COM Server question
From: Brian Muth (bmuth_at_mvps.org)
Date: 04/30/04
- Next message: Egbert Nierop \(MVP for IIS\): "Re: atldbcli.h line 6200 (VC 7.1):"
- Previous message: Igor Tandetnik: "Re: Modeless dialog box with CAxDialogImpl"
- In reply to: fab1usa: "Re: Stupid ATL COM Server question"
- Next in thread: fab1usa: "Re: Stupid ATL COM Server question"
- Reply: fab1usa: "Re: Stupid ATL COM Server question"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 30 Apr 2004 09:22:01 -0700
I had assumed from your original post that you knew how to create an COM
object remotely.
There are a couple ways to do it. One way is to specify the remote server at
the time CoCreateInstanceEx is called. Have a look at the parameters to this
function and you will see. In VB, this is done by
CreateObject(<progid>,<remote server>)
Marshaling of parameters is done through one of two techniques. If you use a
proxy-stub on the client machine, then you can use non-automation compliant
interfaces, since the proxy-stub has all the necessary information to carry
out the marshalling on your behalf. Alternatively, you can use the universal
marshaler, but of course, it can only know about your interface parameters
if it has access to the type library, and therefore you will need to
distribute your type library.
However, registering your type library on the client machine will not
register your coclasses. For that, you either have to register your
proxy-stub or the original server exe (even though you never actually use
the exe on the client machine). This will add the necessary CLSID and the
Interface key to the registry. In addition, an AppID key is added and this
provides the ability to set up security, surrogate, and service settings to
a legacy COM object. This provides the alternate way of specifying a remote
server: DCOMCNFG will use the AppID to record the remote server if one is
specified through its interface.
So, to cut to the chase, what is the fastest way to get you started....
register your exe on the client machine. This will also automatically
register your typelibrary. Then use DCOMCNFG to specify the remote computer.
Once you are comfortable with this, you can do the more advanced types of
remoting, such as using CoCreateInstanceEx to specify the remote machine.
HTH,
Brian
"fab1usa" <anonymous@discussions.microsoft.com> wrote in message
news:30673B50-2D72-4DFC-A9EE-0F03189413DC@microsoft.com...
> Brian,
>
> I guess I'm really not understanding this. Let's say I have a network of
computers. On one computer I develop the server and client. Then I decide
to keep the server where it is but move the client to a second computer.
What I've done so far is run REGTLIB on the second machine with the TLB file
that I copied from the server machine. However, when I try to run the
client app on the second machine, I get an error "ActiveX object not found".
This makes a lot of sense to me. How does the client machine know the IP of
the server machine? Is the IP of the server embedded in the TLB when I ran
REGTLIB? If yes, why can't I inspect it/modify it with DCOMCNFG or some
other tool?
>
> Thanks,
> Brian.
>
- Next message: Egbert Nierop \(MVP for IIS\): "Re: atldbcli.h line 6200 (VC 7.1):"
- Previous message: Igor Tandetnik: "Re: Modeless dialog box with CAxDialogImpl"
- In reply to: fab1usa: "Re: Stupid ATL COM Server question"
- Next in thread: fab1usa: "Re: Stupid ATL COM Server question"
- Reply: fab1usa: "Re: Stupid ATL COM Server question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|