Hi Cetin.
Just digging a bit deeper and , even though the DLL seems to registe ok with REGSVR32,
I I go into Foxpro on the same server and do a Obj= Createobject("MyDll.MyClass") Obj
is not deined....sounds like the DLL may not be reistered correcltly ??

Regards,
gerard




>I was never a fan of VFP COM dlls. I would check if it is registered and could be called directly first, then with the identity of web account (maybe in old one you are impersonating while not in this one). Also check DCOM configuration. It may be disabled at machine level. The best option would be not to use any VFP COM dll.
>Cetin
>
>>Hi Cetin.
>>The Server is not 64bit.
>>This dll was working fine on an old server and I had copied exact folders.
>>Its also woking fine on my development machine.I've recomplied it and it still works fine on
>> my development machine but not on the Production Server
>>
>>Any ideas on where the likely problem would be ?
>>
>>Regards,
>>Gerard
>>
>>
>>
>>>Then you need to compile targeting x86. On an 64 bits OS by default it compiles to 64 and it would fail with anything to VFP.
>>>Cetin
>>>
>>>>Hi Cetin.... if it is 64 bit.. what implicatiuons does it have
>>>>Regards,
>>>>Gerard
>>>>
>>>>
>>>>>>Hi,
>>>>>>I have just moved a DOT Net c# Web App from one server to another.
>>>>>>The web app contains a vfp .DLL do do some file accessing
>>>>>>All bits of the Web app are working, excelpt the VFP .dll
>>>>>>Following message is comng up when I call a method in the DLL
>>>>>>..System.Runtime.InteropServices.ComException
>>>>>>...The Server thre an exception
>>>>>>...Exception form HResult 0x80010105 (RPC_E_SERVERFAULT)
>>>>>>I have registered the DLL on the new server and am logged in with Admin Rights
>>>>>>
>>>>>>Any help appreciated
>>>>>>Regards,
>>>>>>Gerard
>>>>>
>>>>>Gerard,
>>>>>Besides security check if your new server is 64 bits.
>>>>>Cetin