Can't get VB6 Client to talk to VB6 Server Component

[ajones]

This is my first foray into building ActiveX dll's, so maybe I'm missing something very fundamental. Please bear with me.

My development machine is a Windows 2000 Workstation. I'm using VB6 SP5. My application server is Windows 2000 Server. Clients are running either NT 4.0 SP6 or Windows 2000 Workstation.

I created an ActiveX dll project in VB6. It tested out fine. I compiled the dll. Set the compatibility in the project properties to binary. Copied the dll to a test application server. Installed it under Component Services.
Started it up.

I developed a VB6 client - standard exe project. I was able to reference the correct dll through the Project References dialog. It appears as an Reference in the project's vbp file.

I begin to notice trouble when I try to use PDW to create a correct installation script. If I don't pay attention, PDW wants to install the dll I've referenced into my WINNT/System32 directory. If I tell PDW not to install the dll, the client application can't see the dll on the server machine. And I can't seem to find any options to retain the reference to the dll.

Can anyone help me with this?

 

[SmokingCrater]

ajones,

From what I have done with the ActiveX stuff, a copy needs to be on (or at least registered on) the local machine. That is why the PDW tries to install it. Most compiled dll's are default installed into the WINNT/System32. I'm not sure that when you did your development of the standard exe that you pointed at the server. You migth have been pointing to a compiled version that is on your desktop.

In related knowledge, I know that the ActiveX component needs to be registered with the client machine before it can be used. So PDW tries to include the dll so it can be installed on the client machine and registered. What you need to do if you want the ActiveX code to reside on a server, you need to have the install script point to the server (by means of // reference through the network neighborhood, NOT by use of drive letters) to allow the script to register a reference to the DLL. You may end up needing to install the DLL with the standard client exe so the client machine can find the DLL.

Is there a problem with installing the compiled DLL with your standard EXE?

Hope that helps a bit.

-crater

 

[ajones]

Thank you for your thoughtful response. I did, in fact, point to the dll on my server.

The dll contains rules for estimating the complexity of tasks and the time it would take to complete them, based upon values it receives from the client application. The first set of rules is based upon "best gut guess" at the moment and are expected to change dozens of times before being satisfactorily refined based on experience. I was hoping to be able to make those changes to the component only. That's why I don't want the dll on the desktops.

Registration of the dll on the client never occurred to me(registry not being my best subject...). That's what comes of years of uncritically taking whatever PDW happens to offer.

After I posted my question, I read something about msi files. Is this something that might help me?