1
votes

I have an ASP.NET asmx web service running on IIS.

A client is trying to consume the service, and I can see (after a rebuild) that the Global.asax Application_Start is getting hit from his attempt... but the specific function is not getting hit.

This link Getting RAW Soap Data from a Web Reference Client running in ASP.net gives a "solution" for what I'm trying to do, but it didn't work.

I placed the above link's suggestion in my web.config, but no log file is generated even when I successfully call the service myself.

1
What do you see in Fiddler?John Saunders
Nothing... because unfortunately I don't have authority to install a packet monitor tool on this server, since it transmits sensitive information.adam
I mean use Fiddler from a test machine to see what gets sent to the server and what the response is.John Saunders
I'm sure you were aware that ASMX is a legacy technology, and should not be used for new development. WCF should be used for all new development of web service clients and servers. One hint: Microsoft has retired the ASMX Forum on MSDN.John Saunders
Keep in mind that you only need to worry about the features of WCF which are equivalent to those in ASMX. Also, be sure to use .NET 4.0 or above, as WCF configuration is much simpler there.John Saunders

1 Answers

0
votes

If you're looking to trap request/response on the client side, you can connect to ASMX webservices using WCF-style generated proxies just by using a "Service Reference" rather than a "Web Reference", then follow the WCF tracing you linked to for raw data, as well as using System.ServiceModel.MessageLogging for SOAP-specific stuff. Keep in mind that:

  1. the maxdatasize attribute for System.Net will truncate the data logged, so pick a bigger number if your request/responses are larger. Use maxSizeOfMessageToLog with System.ServiceModel.MessageLogging.
  2. remove the raw ascii/hex and only show the xml with tracemode="protocolonly" in the <source name="System.Net"> element

But if you want to trap requests on the server side (i.e. from within your ASMX webservice) you can try the suggestion here, which is to just read the data out of the request stream in Application_BeginRequest and probably also the response stream in Application_EndRequest.