Debugging a WCF Service running in IIS, process not showing in process list
Few days ago, I wanted to debug a WCF service hosted in IIS (on localhost). Sounds simple, just use Visual Studio "Debug > Attach to Process…" command (Ctrl + Alt + P).
However, aspnet_wp.exe (running Windows XP) was not displayed in the list of running processes (while the "Show processes from all users" was checked).
So I started crawling the web to find why this process didn’t show up in the list. And the answer was very simple: this process is not started if no request has been made yet. Simply heading to the .svc URI of the service started the process, which was then available in the list of processes.
SOAP 1.2 message format with BasicHttpBinding
While testing a WCF service running in IIS with a simple Axis2 client, we encountered a content type error:
org.apache.axis2.AxisFault: Transport error: 415 Error: Cannot process the message because the content type ‘application/soap+xml; charset=UTF-8; action="[...]"’ was not the expected type ‘text/xml; charset=utf-8′.
Using MSSoapT, we could see that the content type of the request was application/soap+xml.
So, looks like Axis2 client is using SOAP 1.2 messages and WCF service replies using SOAP 1.1 messages. According to this post by Aaron Skonnard, BasicHttpBinding uses SOAP 1.1 messages.
It is not possible to specify the message encoding in the binding section of the configuration file. Hence, the only way to make the server match the client is by using a CustomBinding that will be like BasicHttpBinding but use SOAP 1.2 instead of SOAP 1.1 as message encoding.
This can be easily achieved in the configuration file by adding a customBinding in bindings section:
<customBinding> <binding name="customHttpBinding"> <textMessageEncoding messageVersion="Soap12" /> <httpTransport/> </binding> </customBinding>
Next, change the endpoint binding to use customBinding and use the bindingConfiguration attribute to point to the newly created binding configuration (in the example, customHttpBinding).
Running the client again worked this time, and MSSoapT was showing application/soap+xml content type in request and response’s HTTP headers.
