System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse request failed with HTTP status 404

Question

I am trying to make some enhancements to a production web app. After quite a bit of unit testing 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:

• the primary web app
• the "primary" webservice (the home page tries to invoke this WS)
• a "secondary" webservice (not yet a problem because home page does not invoke this WS)

I get the following when I try to browse to the home page of the web app typing this into 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 is a bit of the corresponding 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 configured things incorrectly on the staging server. The staging server is Win Server 2003 ServicePack 2 running IIS 6.0. When I published the primary site and the 2 webservices on the staging server called MOJITO I created the physical directories for each on the D drive. Then using INETMGR, I configured the following virtual directories:

• zVersion2
• zVersion2wsSQL
• zVersion2wsEmergency

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

Can my staging versions of the above webservices (named zVersion2wsSQL and zVersion2wsEmergency respectively) co-exist on the same web server with the same IP address?

Please note that when I test the zVersion2wsSQL webservice independently (from INETMGR right-mouse and click Browse) it works as expected (i.e. presenting all the methods of the webservice) like this snippet:

• GetMessageByType MessageName="Get_x0020_Message_x0020_By_x0020_Type"

I can test this webmethod by clicking on it and it presents the Test dialog (because it takes a simple datatype and I am invoking 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 fear I may have rambled with too much information so I will stop but I hope someone can help me as I cannot understand why this request results in a "not found". Thanks.

Answer 1

There are many places where the "name" you give something results in something fairly inscrutable (at least to me) when you have to CHANGE the name. Here I had 2 webservices and one primary site and when I PUBLISHed the webservice(s) to a staging server I took pains to put them in their own physical directory. This staging server hosts the production versions of both webservices so I ran into problems when I went to create the virtual directories for the staging versions of the webservices.

That is, I created them with names distinct from the production versions (e.g. SomeWebSvcVersion2 vs. SomeWebSvc). Then on the Staging server using INETMGR I could Browse these "sites" and the "test" page comes up as expected allowing the INVOKE of webmethods with simple datatypes for input parameters.

I discovered that these "arbitrary" names for the virtual directories are not OK. They must match up with the names in the App.Config for my proxy classes that wrap each web service. So in the case of the error above, the App.Config contained:

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

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

I hope these notes may be helpful to somebody. Case closed.