Hi all,

Using Filemon, we were able to note the different behavior when consuming the WSDL with and without the full version of VFP installed.

With only the VFP runtimes (SOAP, etc) installed the log file showed that only the WSDL file was OPEN/READ/QUERY INFORMATION/CLOSE by W3WP.EXE (this is an IIS component responsible for reading WSDL - i think).

Whereas if we have the full version of VFP installed the log file showed that the WSDL file was OPEN/READ/QUERY INFORMATION/CLOSE by W3WP, then the WSML was OPEN/READ/QUERY INFORMATION/CLOSE by W3WP. At this point, the client was able to successfully call the method of the Web service.

Any thoughts...

>Ah the joys of debugging a VFP Web Service through COM <g>...
>
>Most likely the issue is security. If you can instantiate the server from a standalone EXE or WSH script but not through IIS the first thing to check is security.
>
>I don't think that the VFP IDE installation has anything to do with this...
>
>Unfortunately it's very difficult to debug things like this. The best thing to do is to create an ASP/ASP.NET page and call your COM server from it - that way you can simulate the COM environment a little bit more easily and you might be able to get more detailed error information from that end.
>
>Good luck,
>
>+++ Rick ---
>
>
>
>>Hi all,
>>
>>We have a VFP ws.dll that is installed on IIS. We use a C# wsclient.dll from a remote PC to access the ws.dll on the webserver. Everything runs without problem... until we remove the VFP development environment on the server. This is how it breaks down:
>>
>>1. Full VFP on server.
>> - Everything works.
>>
>>2. Only VFP8 runtimes and SOAP SDK installed.
>> - Error: "WSDLOperation:Instantiating the dispatch object for MyMethod failed."
>> - I can instantiate the ws.dll from a test.exe on this server.
>>
>>We are using Installshield to install the VFP8 runtimes & dependencies. We use the SOAPSDK installer from MS. Any ideas?