System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse error with HTTP status 404

I am trying to make some improvements for a production web application. After quite a bit of testing the modules on my WinXP IIS 5.1 development machine, everything works on my localhost, so I used the Visual Studio 2008 PUBLISH dialog on my Dev PC to push the following projects to a staging server:

  • main web application
  • the "primary" web service (the home page tries to call this WS)
  • the "secondary" webservice (not a problem yet, because the homepage doesn't call this WS)

I get the following when I try to go to the home page of a web application by typing this in my browser: myUglyURL

Server Error in '/zVersion2' Application.
The request failed with HTTP status 404: Not Found.
Description: An unhandled exception occurred during the execution of the current web request.Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Net.WebException: The request failed with HTTP status 404: Not Found.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[WebException: The request failed with HTTP status 404: Not Found.]
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) +431289
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) +204
ProxyZipeeeService.WSZipeee.Zipeee.GetMessageByType(Int32 iMsgType) in C:\Documents and Settings\johna\My Documents\Visual Studio 2008\Projects\ProxyZipeeeService\ProxyZipeeeService\Web References\WSZipeee\Reference.vb:2168
Zipeee.frmZipeee.LoadMessage() in C:\Documents and Settings\johna\My Documents\Visual Studio 2008\Projects\Zipeee\frmZipeee.aspx.vb:43
Zipeee.frmZipeee.Page_Load(Object sender, EventArgs e) in C:\Documents and Settings\johna\My Documents\Visual Studio 2008\Projects\Zipeee\frmZipeee.aspx.vb:33
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +50
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +627

      

Version Information: Microsoft .NET Framework Version: 2.0.50727.3607; ASP.NET Version: 2.0.50727.3082

Here's some relevant source code:

Public wsZipeee As New ProxyZipeeeService.WSZipeee.Zipeee
Dim dsStandardMsg As DataSet  
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles  MyBase.Load
    If Not Page.IsPostBack Then
        LoadMessage()
    End If
End Sub

Private Sub LoadMessage()
    Dim iCnt As Integer
    Dim iValue As Integer

    dsStandardMsg = wsZipeee.GetMessageByType(BizConstants.MsgType.Standard)
End Sub

      

I suspect I may have misconfigured the files on the staging server. The staging server is Win Server 2003 ServicePack 2 with IIS 6.0. When I published the main site and 2 web services on the MOJITO staging server, I created physical directories for each of the D drives. Then, using INETMGR, I configured the following virtual directories:

  • zVersion2
  • zVersion2wsSQL
  • zVersion2wsEmergency

All of the above is configured to use a new application pool that I configured and named zVersion2aspNet20 . The default website for this MOJITO device is configured to use ASP.NET 1.1 and the IP address is set to (All Unassigned) . The production versions of the last 2 web services run on the MOJITO machine (ZipeeeService and EmergencyService respectively).

Can my intermediate versions of the aforementioned web services (called zVersion2wsSQL and zVersion2wsEmergency respectively) coexist on the same web server with the same IP address?

Note that when I test the zVersion2wsSQL web service myself (from the right and click INETMGR and click Browse) it works as expected (ie presents all the web service methods) like this snippet:

  • GetMessageByType MessageName = "Get_x0020_Message_x0020_By_x0020_Type"

I can test this web method by clicking on it and it presents the Test dialog (because it accepts a simple datatype and I call it on localhost (i.e. MOJITO):

**Get Message By Type**

**Test**
To test the operation using the HTTP POST protocol, click the 'Invoke' button. 
Parameter Value 
iMsgType: _______                    [INVOKE button]

SOAP 1.1 ....etc. 

      

I'm afraid there might be too much information, so I'll stop, but hope someone can help me as I don't understand why this query results in "not found". Thank you.

+2


a source to share


1 answer


There are many places where the "name" you give leads to something rather incomprehensible (at least to me) when you need to CHANGE the name. Here I had 2 web services and one main site, and when I published the web service (s) on a staging server I did my best to put them in my own physical directory. This staging server hosts production versions of both web services, so I ran into problems when creating virtual directories for the staging versions of the web services.

That is, I created them with different names from production versions (for example, SomeWebSvcVersion2 and SomeWebSvc). Then on a staging server using INETMGR, I could browse these "sites" and a "test" page appears as expected, allowing INVOKE web methods with simple data types for props.

I found that these "arbitrary" names for virtual directories were out of order. They must match the names in App.Config for my proxy classes that wrap each web service. So in case of error above App.Config contains:



<applicationSettings>
    <ProxyZipeeeService.My.MySettings>
        <setting name="ProxyZipeeeService_WSZipeee_Zipeee" serializeAs="String">
            <value>http://localhost/ZipeeeWebService/Zipeee.asmx</value>
        </setting>
    </ProxyZipeeeService.My.MySettings>
</applicationSettings>

      

The reference.vb file compiled into my proxy library proxyclass requires a virtual directory on a staging server called ZipeeeWebService, and my attempts to configure a new version published to a staging server with a different virtual directory name were wrong.

I hope these notes can be helpful to someone. Case is closed.

+4


a source







All Articles