Hmmm....
but surely if you've got a server name the chain of events should be:
1) connect to server
2) ask remote server about given PROGID (or CLASID)
CreateObject can accept a CLSID can;t it?
It really doesn't make a lot of sense to me to register a remote server
locally unless this is for performance reasons? I mean, I'm not trying to
reengineer COM here (or may I am) but you should be able to do this without
local registry entries. The way I see it, AFTER you've made you 1st call to
the remote server, the component environment should have the choice to add
details to the client registry (like a DNS cascade) to speed up future look
ups.
joel
Quote:
> WSC, DCOMI try not to know any more about the mechanics of COM/DCOM than I
> absolutely need, but I'll venture a semi-educated guess ;-)...
> CreateObject accepts a progid and a server name. The progid needs to be
> translated into a classid for CoCreateInstance[Ex]. That requires at a
> minimum that the progid be registered locally so it can be looked up. The
> RemoteServer key (if present) will be overridden by the server name in the
> CreateObject call.
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
> Hi,
> what purpose does the 'server' param serve? You have to locally register
the
> remote component so this param is redundant (I have proved this).
> My gut feeling is that you SHOULD be able to do both of these i.e.
> - register the remote COM locally so that you address it as if it were
> locally by OLE redirects yuo behind the scenes to the remote server
> - specify a PROG/CLSID AND a remote server; OLE then has all the necessary
> info to find the remote component - this should NOT need local
registration.
> Why cannot I not get the remote server to work unless the REGEDIT
> information is exported locally (as per MSDN)
> regards
> Joel Hughes
WSC, DCOM