Home/ Questions/Q 965113
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T01:56:30+00:00

We’ve having trouble deploying a web service that works in our development environment, but

  • 0

We’ve having trouble deploying a web service that works in our development environment, but not in production. Part of the problem is that our production servers are load-balanced, so to upgrade one of the servers, we have to take it out of the load-balance and try to test the sever in isolation, which is a challenge.

The computer I’m working on is called Web01 and the computer I’m using to test is called Ts01. On both machines, I’ve modified the hosts file to redirect example.com to the appropriate IP of the web site on Web01.

I’m testing two ways of accessing the web service on each machine:

  • A simple browser call to http://www.example.com/services/myservice.asmx?WSDL.
  • A VB6 test app that calls the web service using the WSDL referenced above via SOAPClient.

Here are the results of the test:

                   Browser              VB6 App
    Ts01             OK                   OK
    Web01            OK                  ERROR

The test seems to work OK for every situation except the VB6 app installed on the web server. The Error I get back is :

-2147024809 – WSDLReader:Loading of the WSDL file failed HRESULT=0x80070057 – WSDLReader:XML Parser failed at linenumber 0, lineposition 0, reason is: The system cannot locate the object specified.

HRESULT=0x1

I get the same error back on Ts01 if I supply a bad WSDL address in the VB6 app. It seems as if the VB6 application on Web01 can’t access the web service dll on Web01, which is a big problem.

It may be worth noting that it works on my local developer machine as well, where I have the VB6 app and the web service installed on the same machine.

Why might the VB6 app be having trouble communicating with the web service via SOAPClient when run from the same box that the web service exists?

I used fiddler to inspect the headers of the requests on my local machine calling our dev server. Here’s the difference between the browser and SOAPclient requests:

Browser:

GET http://devserver/services/myservice.asmx?WSDL HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: devserver
Cookie: SIFR-PREFETCHED=true

SOAPClient (from VB6 App):

GET http://devserver/services/myservice.asmx?WSDL HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Host: hbhswebnet
Connection: Keep-Alive
Pragma: no-cache

I’m not sure if that information is helpful, but perhaps it is.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here’s a general pattern:

    Q: "x" works in the browser, but fails in a program that’s doing the same thing the browser is doing. What’s wrong?

    A: the program is not doing the same thing the browser is doing.

    Browsers explicitly set headers that your program is not setting (especially since you’re using the very obsolete SOAPClient). Various pieces of networking equipment and software may look at these headers in deciding how to respond to your requests.

    You should look at the network traffic for both cases (browser and program) using Fiddler or something, then look carefully for differences between the way the browser behaves and the way your program behaves. You may then either change the program to be like the browser, or ask your networking people to please reduce security so that your program can access the service.

    • 0