Board index » delphi » Registering DCOM Server on Client (from 3 DCOM Questions)

Registering DCOM Server on Client (from 3 DCOM Questions)

Hi,

Original Question :

Quote
>Is there anyway around always registering the server on the client
>machines ? If not, what would be the easiest way to register the server
>without having to distribute the servers to all clients and registering
>them by running the servers. I.e. is there an easy way to have the
>client register the server without distributing any server components?

There seem to be some conflicting ideas on whether you can get away with
not registering your DCOM server on a client machine. From trying all
suggestions, i've come to the conclusion you cannot, however I could be
wrong ! I'd like to get to the bottom of this and find a way to make a
remote connection work by registering as little as possible on the local
client. I summarized all suggestions and listed their shortcommings.
Hopefully some of you DCOM Guru's out there will tell me (and everyone
else) what the real scoop is.

To summarize here are some of the opinions expressed :

1. (HBZhang) suggest to use the serverGUID directly instead of the
classname, i.e. something like this
ExtractIntf := CreateRemoteComObject(GetComputerName,
StringToGUID('{DBA207C7-86E9-11D2-B11C-9AF3D2000000}')) as
IExtractSourceClass;

Well, using the serverGUID or the classname is not going to make a
difference, since we are still trying to cast it as an
IExtractSourceClass Interface. When connecting to the server, it will
connect, the server will launch on the remote machine, immediatly die
and you will get an error "Interface not supported" on the local client.

2. (Alexey Dynnikov) writes : Register the server's typelibrary only.
This is enough.

Well if you only register the type library, i.e. enter the GUID for the
TLB (and its associated subkeys) in the registry , you will still get
the same "Interface not supported" error.

3. (Binh Ly) writes : you need to get the interface (with the tlb) and
coclass (at least the GUIDs) entries onto every client machine registry
and recommends doing this by registering the server on each machine or
doing it manually or through an install.

OK, I'm not sure how you guys (and girls) feel but registering the
server on each client could be a little cumbersome if you have a 1000
clients, I do not want to distribute the server to each client just to
register it.
Next option is to register the Interface and TypeLibrary in the registry
manually or by some install. I played around with this and got it to
work. I'm not quit sure what Binh means with registering the coclass,
maybe someone does.

I made the following entries :

in HKEY_CLASSES_ROOT\TypeLib

KEY : {DBA207C4-86E9-11D2-B11C-9AF3D2000000}
   SUBKEY : 1.0  VALUE : "Project1 Library"
        SUBKEY : 0
              SUBKEY : win32 VALUE : "d:\build\etl\extractsource.exe"

and in HKEY_CLASSES_ROOT\Interface

KEY : {DBA207C5-86E9-11D2-B11C-9AF3D2000000}
   SUBKEY : ProxyStubClsId VALUE : {232....3323}
   SUBKEY : ProxyStubClsId32 VALUE : {232....3323}
   SUBKEY : TypeLib VALUE : {232....3323}

With these entries it will work, however the strange side effect is that
I need the win32 SUBKEY pointing to a local copy of the server (not quit
what I had in mind). In fact if the copy of the local server isn't there
it will not work and you'll get the "Interface not supported" error.

CONCLUSION

OK, obviously I'm still missing something. I think I'm close but I'm
still not sure what to do in order to make it work without distributing
my server to all my clients ?

Hopefully someone can give the final answer.

If you made it to the end of this message, thanks.

Mike.
m...@exosolutions.com

 

Re:Registering DCOM Server on Client (from 3 DCOM Questions)


Hello,

Answers:

1. You can use the ServerGuid (and not need the interface nor typelib on
client machine) provided you only use late-binding. If you early-bind with
the IExtractSourceClass, you will need that interface entry on the local
machine together with the type library file (or server EXE file which
already contains the type library bound to it) on the client machine

2. Registering the type library means: deploying the type library on the
client machine and then registering it, either using the tregsvr utility or
using the LoadRegTypeLib API. If you manually enter the interface and type
lib guids and definitions in the registry, they still need to point to a
physical type library file on the client machine.

3. The Win32 subkey for the type library can point to the YourServer.tlb
file (instead of YourServer.exe) that needs to exist on the client machine
(this is done automatically if you register your type library using #2
above). The coclass entries I am referring to are necessary if you don't use
the CreateRemoteComObject (or CoCreateInstanceEx) function - these entries
are the ones that are found under [HKCR\CLSID\blah blah] that pertain to
your server's coclasses - you can inspect these entries on the machine where
you registered your server EXE file.

have fun,
--
Binh Ly
Brickhouse Data Systems, Inc.
http://www.brickhouse.com
    Mike van Thiel wrote in message <3664B241.F2803...@exosolutions.com>...
    Hi,
    Original Question :

    >Is there anyway around always registering the server on the client
    >machines ? If not, what would be the easiest way to register the server
    >without having to distribute the servers to all clients and registering
    >them by running the servers. I.e. is there an easy way to have the
    >client register the server without distributing any server components?

    There seem to be some conflicting ideas on whether you can get away with
not registering your DCOM server on a client machine. From trying all
suggestions, i've come to the conclusion you cannot, however I could be
wrong ! I'd like to get to the bottom of this and find a way to make a
remote connection work by registering as little as possible on the local
client. I summarized all suggestions and listed their shortcommings.
Hopefully some of you DCOM Guru's out there will tell me (and everyone else)
what the real scoop is.

    To summarize here are some of the opinions expressed :

    1. (HBZhang) suggest to use the serverGUID directly instead of the
classname, i.e. something like this
    ExtractIntf := CreateRemoteComObject(GetComputerName,
StringToGUID('{DBA207C7-86E9-11D2-B11C-9AF3D2000000}')) as
IExtractSourceClass;

    Well, using the serverGUID or the classname is not going to make a
difference, since we are still trying to cast it as an IExtractSourceClass
Interface. When connecting to the server, it will connect, the server will
launch on the remote machine, immediatly die and you will get an error
"Interface not supported" on the local client.

    2. (Alexey Dynnikov) writes : Register the server's typelibrary only.
This is enough.

    Well if you only register the type library, i.e. enter the GUID for the
TLB (and its associated subkeys) in the registry , you will still get the
same "Interface not supported" error.

    3. (Binh Ly) writes : you need to get the interface (with the tlb) and
coclass (at least the GUIDs) entries onto every client machine registry and
recommends doing this by registering the server on each machine or doing it
manually or through an install.

    OK, I'm not sure how you guys (and girls) feel but registering the
server on each client could be a little cumbersome if you have a 1000
clients, I do not want to distribute the server to each client just to
register it.
    Next option is to register the Interface and TypeLibrary in the registry
manually or by some install. I played around with this and got it to work.
I'm not quit sure what Binh means with registering the coclass, maybe
someone does.

    I made the following entries :

    in HKEY_CLASSES_ROOT\TypeLib

    KEY : {DBA207C4-86E9-11D2-B11C-9AF3D2000000}
       SUBKEY : 1.0  VALUE : "Project1 Library"
            SUBKEY : 0
                  SUBKEY : win32 VALUE : "d:\build\etl\extractsource.exe"

    and in HKEY_CLASSES_ROOT\Interface

    KEY : {DBA207C5-86E9-11D2-B11C-9AF3D2000000}
       SUBKEY : ProxyStubClsId VALUE : {232....3323}
       SUBKEY : ProxyStubClsId32 VALUE : {232....3323}
       SUBKEY : TypeLib VALUE : {232....3323}

    With these entries it will work, however the strange side effect is that
I need the win32 SUBKEY pointing to a local copy of the server (not quit
what I had in mind). In fact if the copy of the local server isn't there it
will not work and you'll get the "Interface not supported" error.

    CONCLUSION

    OK, obviously I'm still missing something. I think I'm close but I'm
still not sure what to do in order to make it work without distributing my
server to all my clients ?

    Hopefully someone can give the final answer.

    If you made it to the end of this message, thanks.

    Mike.
    m...@exosolutions.com

Re:Registering DCOM Server on Client (from 3 DCOM Questions)


Hi again,

Quote
bly wrote in message <742cuo$op...@forums.borland.com>...
>Hello,

>Answers:

>1. You can use the ServerGuid (and not need the interface nor typelib on
>client machine) provided you only use late-binding. If you early-bind with
>the IExtractSourceClass, you will need that interface entry on the local
>machine together with the type library file (or server EXE file which
>already contains the type library bound to it) on the client machine

>2. Registering the type library means: deploying the type library on the
>client machine and then registering it, either using the tregsvr utility or
>using the LoadRegTypeLib API. If you manually enter the interface and type
>lib guids and definitions in the registry, they still need to point to a
>physical type library file on the client machine.

>3. The Win32 subkey for the type library can point to the YourServer.tlb
>file (instead of YourServer.exe) that needs to exist on the client machine
>(this is done automatically if you register your type library using #2
>above). The coclass entries I am referring to are necessary if you don't
use
>the CreateRemoteComObject (or CoCreateInstanceEx) function - these entries
>are the ones that are found under [HKCR\CLSID\blah blah] that pertain to
>your server's coclasses - you can inspect these entries on the machine
where
>you registered your server EXE file.

Also if you use the coclass entries, you will need to configure an AppId
(HCKR\AppId) entry for all coclasses that will point to the remote machine.
You can play with DCOMCNFG to get a feel for how the AppId works.

have fun
binh

Re:Registering DCOM Server on Client (from 3 DCOM Questions)


Quote
Mike van Thiel wrote in message <3664B241.F2803...@exosolutions.com>...

    Hi,
    I made the following entries :

    in HKEY_CLASSES_ROOT\TypeLib

    KEY : {DBA207C4-86E9-11D2-B11C-9AF3D2000000}
       SUBKEY : 1.0  VALUE : "Project1 Library"
            SUBKEY : 0
                  SUBKEY : win32 VALUE : "d:\build\etl\extractsource.exe"

    and in HKEY_CLASSES_ROOT\Interface

    KEY : {DBA207C5-86E9-11D2-B11C-9AF3D2000000}
       SUBKEY : ProxyStubClsId VALUE : {232....3323}
       SUBKEY : ProxyStubClsId32 VALUE : {232....3323}
       SUBKEY : TypeLib VALUE : {232....3323}

    With these entries it will work, however the strange side effect is that I need the win32 SUBKEY pointing to a local copy of the server (not quit what I had in mind). In fact if the copy of the local server isn't there it will not work and you'll get the "Interface not supported" error.

    CONCLUSION

    OK, obviously I'm still missing something. I think I'm close but I'm still not sure what to do in order to make it work without distributing my server to all my clients ?

    1) The SUBKEY : win32 VALUE : "d:\build\etl\extractsource.exe"  can be replaces by
              SUBKEY : win32 VALUE : "d:\build\etl\extractsource.tlb"
2) Register your typelibrary on client to create all this keys. The words "typelibrary registration" means that the two API function are called (a) LoadTypeLib (b) RegisterTypeLib. You can call them from your setup program or by running tregsvr utility with the -t switch. Examlpe
tregsvr -t d:\build\etl\extractsource.tlb

Be happy

--
Alexey A. Dynnikov <al...@chat.ru>
http://www.chat.ru/~aldyn
ICQ 18267212

Other Threads