Running Dll's on Server 2

[BML]

Hi,

I have one VB dll registered on MyServer (Windows NT), that was compiled on Windows 98.

When I call CreateObject("MyDll.CmyClass", MyServer) it raises an error "ActiveX can't create object".

Why ? regards,

Bruno Loureiro
<brunoloureiro@usa.net>

 

[Ruairi]

To run a dll on the server you have to compile the project with remote server files (it's in project properties) then theres a .vbr file that can be registered on the remote server. This is needed to marshall the calls across the network. I think you could also map a drive to the server, register the dll from that drive, and treat it as local (probably the best idea). Ruairi

Could your manufacturing facility benefit from real time process monitoring? Would you like your employees to be able to see up to the minute goal and actual production?
For innovative, low cost solutions check out my website.

http://www.plccontroltechnologies.com

 

[BML]

Hi Ruairi,

how can I register the .vbr file on the remote server?

regards,

Bruno Loureiro
<brunoloureiro@usa.net>

 

[Ruairi]

Heres an excerpt from the MSDN library. It looks like this may only work with .exe servers. Sorry i can't offer more help. I looked into this as one way of distributing a multiuser app a while back, but decided not to use it because i never could get everything to work right.

How To Use Clireg32.exe for Remote Automation
Last reviewed: January 20, 1997
Article ID: Q155939
The information in this article applies to:
Microsoft Visual FoxPro for Windows, version 5.0


SUMMARY
This article provides an explanation of Clireg32.exe and how it is used for remote automation.



MORE INFORMATION
The Clireg32.exe component allows you to register an OLE server (.exe) remotely. It differs from the Remote Automation Connection Manager (RacMan) in that the server does not need to be located on the machine registering it. The Setup Wizard handles the maintenance of registering remote servers for you.

NOTE: Remote servers and Clireg files are stored in the \Windows\Olesrv\ directory, which is similar to Visual Basic if it is installed via the Setup Wizard.

The Clireg32.exe program takes a number of parameters. The only required one is the name of the .vbr file (generated with the server during build):


Clireg32 myexesvr.vbr


In order to fully register a remote server, you must provide the network name, network protocol, and security access. Clireg32 prompts you with a dialog box if these options are not passed. For a list of all the parameters, simply execute Clireg32.exe by itself.

Ruairi

Could your manufacturing facility benefit from real time process monitoring? Would you like your employees to be able to see up to the minute goal and actual production?
For innovative, low cost solutions check out my website.

http://www.plccontroltechnologies.com

 

[jmarler]

If you just map a drive to the fileserver and then register the DLL locally, then when you instantiate the object, the library will be brought across the network and loaded into the memory of the local machine and you will lose an benefit of having a backend server. Also, if the COM object is a DLL (In-process COM server), then it needs to have a surrogate process in which to load on the other machine. This is normally DLLHost.exe or MTS. To do the cross network call, place the DLL in a package on MTS on the fieserver and then export the package. This will produce and EXE. Run this exe on the client machine and then any calls to create the object will be sent by the SCM to the MTS box.

 

[Antzz]

You cannot run a DLL on a remote server. However an Exe can be run on a remote server using DCOM. To run a DLL in a remote server, you have to use something like MTS(just like jmarler suggested) but then again MTS will only work with DLLs and not with EXEs. Also, it is always better to use WIndows NT machines rather then Windows 95/98 when you are using DCOM.

 

[markSaunders]

why is is better to use WinNT rather than Win9x for using DCOM? Mark Saunders

 

[Antzz]

WinNT wins hands down Mark. No doubt about that. NEVER use Win9x for DCOM stuff.

 

[markSaunders]

but i presume using a win9x machine for accessing a DCOM component (i.e. as the client) poses no problems? - also, why - i realise there are major security issues with win9x but is this the only reason for such advice?
cheers Mark Saunders

 

[Antzz]

Stability is another issue too . My experinces with Win9x have not been pleasant ones...Win NT is surely recommended. If you love Win9x.. well....u got it...