You should not do it like this. Use Com/Dcom. Don´t register the dll with regsvr32, use the component services (start/administrative tools/comp serv) on W2K or XP. This is far superior compared to regsvr32. If you then want to deploy to another machine you can create a package (dcom) so you can deploy on a different machine. This dcom-package registers the dll on a seperate machine. The process, however, will still run on the original machine. Doing this is easy. In the Component Services you must (!) select both the dll and the tlb file. Failing to do so will result in a incomplete dcom-package.


>Yes.
>
>The command I used was
>
>

regsvr32 "S:\PC Source\SalesLink 3.1.0\test\myproject.dll"

>
>where "S:" is a network drive.
>
>you said I should put
>
>

regsvr32 \\YOTTA\Path\YourDLL.DLL

>
>but I cannot put
>
>

regsvr32 "\\YOTTA\S:\PC Source\SalesLink 3.1.0\test\myproject.dll"  or
>regsvr32 "\\YOTTA\PC Source\SalesLink 3.1.0\test\myproject.dll"

>
>because regsvr32 cannot locate the DLL.
>
>The object is registered because I can create it using CREATEOBJECT(). At this stage I am doing everything locally.
>
>Regards
>Geoff Scott
>
>
>>Did you tried registering the class how i mentioned with regsvr32
>>
>>the problem is that when you try to create an obeject from a DLL that resides in a Server, the createobject searches in the local windows registry a DLL entry which is located in a directory named "SERVER".
>>
>>Every ActiveX DLL that you want to access has to be registered, if you have a ActiveX DLL in your PC, in order to use it you have to register it, the same with a ActiveX DLL that resides in a remote server, regardedless if they have or not the same name, windows will create a unique name for both of them.