 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / August 2005Can't reach remote DLL from client via DCOM
I have a utility that I wrote which connects to an ActiveX EXE that runs on a number of remote boxes. It works fine on my machine and any machine which has VB6 installed on it. I cannot, for the life of me, get it working on a workstation that does not have VB. The VB runtime is installed, as I can run the app itself. I just can't connect to any remote boxes. The way I connect is with the CreateObject command, which allows me to specify the remote box at runtime. Attempting to connect hangs for a bit, finally producing an error stating that the remote machine is unavailable. I have tried various techniques, including: 1. Copy the server exe itself onto the new client. Register the component. 2. Register the TLB. 3. clireg32 3a. clireg32 serverapp.exe 3b. clireg32 serverapp.exe /vbr:serverapp.vbr 3c. clireg32 serverapp.exe /vbr:serverapp.vbr /d 4. I tried hard-coding a default box name into the clireg32 dialog. I tried switching the protocol. Interestingly enough I couldn't even run clireg32 at first, as AUTPRX32.DLL was missing. I manually hunted that file down on my box and put it on the client box. Registering this DLL did not help. Using FILEMON, I noticed it was being searched for in windows\system32, so I had to copy it there. I saw no other DLL failures through FILEMON, not even AUTMGR32.EXE, or whatever it's called. Didn't seem to be used. I'm at my whitt's end! I assume the ActiveX EXE is also registered on the client machine Todd, and that it has the same GUIDs there as on the remote machines. CreateObject resolves the ProgID to a ClsID via the local registry before requesting a class instance from the remote machine. What error message do you get? Can you successfully run the client on those remote machines, i.e. eliminating the cross-machine aspect? Is your remote ActiveX EXE configured with dcomcnfg.exe? Are you logged in using a domain account or a local account on the client machine? Tony Proctor > I have a utility that I wrote which connects to an ActiveX EXE that runs on > a number of remote boxes. It works fine on my machine and any machine which [quoted text clipped - 26 lines] > > I'm at my whitt's end! Thanks for taking the time to help. Yes, I tried registering the server on the client, as listed in step 1. I'd rather not have to do this, but I assumed it would be a guaranteed fall-back, which it was not. Ideally I wouldn't have to deploy the server app for clients to connect to it, as I'd never want them running the server app locally. The client works just fine from other machines, including the server itself. We do, indeed use dcomcnfg, as we need to ensure the server app launches under a specific account. Everything's using domain log ins. I will research this issue some more today, starting with looking up the GUID by class string and verifying it on both ends. ps: do you know what enables a component to appear in dcomcnfg? It's been a mystery to us. The server app does NOT appear in the listing on this machine in question, yet it does appear in mine. Not that I want to use dcomcnfg at the client, but hey - I should be able to repoint the server app on the client to the remote box, but obviously something's missing from the registry if the file. > I assume the ActiveX EXE is also registered on the client machine Todd, and > that it has the same GUIDs there as on the remote machines. CreateObject [quoted text clipped - 45 lines] > > > > I'm at my whitt's end! The reason the component needs to be registered on the client is not as a fall-back Todd. The CreateObject has to be able to convert the ProgID to a ClsID via the local registry before talking to the remote machine. The EXE is not invoked locally, unless you specifically ask for that. If this were the problem, though, then I seem to remember there's a very specific error return that you'd get. Unfortunately, I can't remember what it is. dcomcnfg automatically creates an AppID for each ActiveX EXE. The GUID used for this AppID is taken from the ClsID of the first class it finds in that component. Hence, it can be a random choice. A common point of confusion is that dcomcnfg doesn't list all the classes in your component. However, it only needs to display one since the dcom settings apply to the whole EXE rather than any specific class. Hence, whichever class is displayed is good enough. It's just a bit confusing unless you know what it's trying to do. If you don't get any classes displayed from your EXE at all then it points to a registration problem. I'd then check the HKEY_CLASSES_ROOT on the remote machine for the relevant ProgID, and cross-reference it with the HKEY_CLASSES_ROOT\ClsID area to make sure that ProgID and ClsID are both there and consistent. If you want to avoid using the ProgID completely, then you could call CreateObject with a moniker such as: CreateObject ("new:{GUID}") I'm not totally certain but I believe this should provide enough information to start talking directly to the remote machine, and so avoid having to have your EXE registered on the client machine simply to translate the ProgID. Tony Proctor > Thanks for taking the time to help. > [quoted text clipped - 75 lines] > > > > > > I'm at my whitt's end! |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.