ASP.NET Mono: How to send SOAP instead of HTML? - asp.net

Question

I have an ASP.NET web service based on SOAP built on top of Mono.
If I throw exceptions inside the service, the exceptions remain on the HTTP+HTML level. What I'd like to do is send always all exceptions as SOAP responses, i.e. I don't have any normal aspx pages (everything should work with SOAP).
I've tried handling all exceptions in the Global.asax.cs file within the Application_Error() method, but it seems to always send the exceptions as HTML.
What I see is the generic ASP.NET error page.
My SOAP client, when pointed to the HTML, informs me that it cannot parse HTML.
Sending SOAP from the server works nicely when no exceptions are thrown.
I've studied various web sources and learned that Application_Error shouldn't be used for SOAP exception handling from this resource:
Handling and Throwing Exceptions in XML Web Services
Do I have to implement my own HTTP Module or
ExceptionUtility Class or HTTP Handler?
I am running this on my development machine:
Version information: Mono Runtime Version: 2.10.5 (Debian 2.10.5-1); ASP.NET Version: 4.0.30319.1
I am testing this with MonoDevelop's built-in xsp HTTP server inside Ubuntu 11.10.
Here is my test code:
Global.asax.cs:
using System;
using System.Collections;
using System.ComponentModel;
using System.Web;
using System.Web.SessionState;
using System.Web.Services.Protocols;
namespace SoapTaikina
{
public class Global : System.Web.HttpApplication
{
protected virtual void Application_Start (Object sender, EventArgs e)
{
Backend.Initialize();
}
protected virtual void Application_Error (Object sender, EventArgs e)
{
// This doesn't appear to be executed when Foo() throws an exception.
// I cannot catch the Foo() constructor exception here.
throw new SoapException("This is never reached.", null);
}
// These are not used in this example.
protected virtual void Session_Start (Object sender, EventArgs e) { }
protected virtual void Application_BeginRequest (Object sender, EventArgs e) { }
protected virtual void Application_EndRequest (Object sender, EventArgs e) { }
protected virtual void Application_AuthenticateRequest (Object sender, EventArgs e) { }
protected virtual void Session_End (Object sender, EventArgs e) { }
protected virtual void Application_End (Object sender, EventArgs e) { }
}
}
Foo.asmx.cs:
using System;
using System.Web;
using System.Web.Services;
namespace SoapTaikina
{
public class Foo : System.Web.Services.WebService
{
public Foo()
{
// This may throw an Exception which will not be caught in
// Application_Error().
//
// This is the problem spot.
Backend2.InitializeMoreStuff();
}
[WebMethod]
public bool DoStuff() {
// This works fine and returns a SOAP response.
return true;
}
}
}

Answer 1

First, theory
Application_Error is never fired according to .NET Framework requirements. This is because the pipeline that runs pages is different from the one that runs web services. Also, notice that throwing exceptions in Application_Error is a very bad idea.
I found that testing web services from the browser (where, and probably because, accept header is not set to application/soap+xml but to text/html) makes a plaintext message appear. If the client is a SOAP proxy (ie you generated in Visual Studio/MonoDevelop from the web service's WSDL) and inherits from SoapHttpClientProtocol then it is expected that the exception is always thrown as SOAP fault.
Second, practice.
You do var f = new Foo() from Application_Start. This is wrong because the web service skeleton class is instantiated fresh new on every HTTP/SOAP request, and should never be initialized in the special Application_Start method that is run on the very first request and without the request itself bein processed yet. Also, you should avoid to do complex things (that may throw exceptions) in web service's constructor. This is just a bad design, not a non-compiling or non-working solution.
Your problem probably occurs because the ASP.NET pipeline never reached the point where the request is mapped to a web service handler rather than a page handler, firing default behaviour. Tried to find the code in mono repository, no luck :)
I suggest you to first remove any WS initialization in Application_Start, and if you said you don't really need it, throw away Application_Error